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EXECUTIVE  SUMMARY 


V 

The  Ada  programming  language  has  been  available  to  software  developers  for  several  years, 
yet  its  acceptance  into  the  real-time  embedded  applications  for  which  it  was  developed'^!]*. 
has  been  less  than  universal.  Although  many  staff  software  engineers  were  quick  to  embrace 
the  language  ^2],  they  soon  realized  that  the  ability  to  assert  control  over  the  hardware  was 
greatly  restricted  with  the  available  Ada  compiler  implementations.  The  result  was  a 
disappointment,  and  often  project  delays  were  due  specifically  to  the  use  of  Ada  on  the 
project.  Performance  of  initial  compilers  (and  even  many  contemporary  compilers)  was  far 
below  that  achievable  from  alternative  languages.  In  the  "^at  of  battle'^sociated  with 
hardware/software  integration,  suffident  time  was  not  available  to  work  out  the  (j-roblem*; 
with  the  compilers,  and  often  cumbersome  work-arounds  were  iraplem'nted.  The  impact  of 
these  initial  costly  experiences  has  served  to  retard  the  adoption  of  Ada  for  real-time 
embedded  applications,  although  its  use  in  other  applications  has  exceeded  most 
expectations.  ^ 

The  purpose  of  this  project  was  to  address  the  difficulties  in  real-time  Ada  programming 
from  an  "Ada  technology*^  perspective,  and  to  provide  accurate  details  on  some  of  tlie 
perceived  problems  with  Ada.  The  project  involves  the  development  of  a  typical  weapon 


system  application  with  severe  performance  requirements.'VThe  application  is  synthetic,  but 
resembles  many  similar  weapon  systems.  In  some  case:,  simplifications  were  adopted 
because  they  did  not  alter  the  nature  of  the  application  sfgmficantly,  and  may  have  restricted 
the  ability  to  make  the  results  of  the  project  available.  | 

L  fva  )r^ 


The  approach  used  was  to  develop  the  softv^are  to  be  independent  of  the  target  architecture, 
and  to  increase  the  number  of  processors  as  necessary  to  achieve  the  required  system 
performance.  The  unit  of  distribution  supported  was  the  Ada  task.  The  project  utilized  a 
commercially  available  Ada  compiler  and  supported  the  Ada  semantics  by  extending  the 
runtime  system  without  modifying  the  vendor  supplied  runtime  code.  Initially,  it  was 
intended  to  use  a  "source  code  translation"  method  to  achieve  the  distribution.  This  would 
translate  the  input  source  according  to  a  configuration  table  and  generate  individual 
programs  for  loading  on  the  target  processors.  This  technique  was  not  used  because  it  was 
found  to  be  somewhat  easier  to  apply  a  link/edit  step  on  the  output  of  the  compiler  to 
achieve  the  desired  effect.  In  general,  it  was  felt  that  any  production  project  should  use  a 
compiler  that  specifically  supports  the  distribution  of  Ada  programs.  Full  Ada  semantics 
including  the  Ada  rendezvous  were  preserved  across  the  distributed  system  so  that  no  source 
code  changes  were  necessary  to  alter  the  allocation  of  tasks  to  processors.  This  allocation 
was  done  using  a  distribution  table  that  specified  the  object  names,  the  processor  ID,  and 
relevant  characteristics. 

The  projea  has  identified  areas  in  the  Ada  language  definition  that  are  vague  and  need 
special  clarification  with  respect  to  distributed  systems.  Although  some  of  these  have  been 
identified  previously,  no  resolutions  have  been  adopted  and  it  is  hoped  that  this  work  will 
shed  some  insights  into  how  they  may  be  resolved  in  future  interpretations/revisions  of  the 
language.  Furthermore,  the  results  of  the  demonstration  should  help  to  indicate  what  is 
achievable  using  Ada,  and  how  performance  can  be  improved  by  judicious  use  of  language 
features.  Finally,  the  project  demonstrates  that  it  can  be  practical  to  use  distributed  systems 
effectively  within  the  Ada  model  of  concurrency  and  that  the  diificuity  of  adding  additional 
processors  can  be  minimized.  The  work  performed  on  this  project  will  be  available  to  other 


researchers  and  compiler  writers  to  aid  in' understanding  and  resolving  the  real-time  Ada 
issues. 

The  project  used  the  Ada  tasking  model  exclusively  to  achieve  concurrent  execution.  It  was 
our  objective  to  fully  utilize  the  real-time  features  of  Ada  to  meet  performance  objectives. 
Unfortunately,  we  found  that  while  the  latest  compilers  are  starting  to  provide  these 
fe-'itures,  they  are  still  quite  far  from  being  error  free.  We  spent  close  to  ninety  percent  of 
Our  integration  time  analyzing  problems  that  were  the  result  of  runtime  and  code  generator 
anomalies.  If  this  had  been  other  than  a  demonstration  project,  we  certainly  would  have 
been  forced  to  alter  the  design  to  limit  the  features  used.  Application  developers  should  be 
prepared  to  spend  additional  time  during  integration  to  resolve  such  problems  if  they  expect 
to  use  Ada  as  it  was  intended  to  be  used  for  real-time  systems. 
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1.  Introduciion 

This  paper  is  divided  into  two  separate,  but  related  topics.  The  first  topic  covers  the  details 
of  the  application  chosen  for  the  demonstration.  Since  the  application  was  developed  with 
the  intention  of  running  on  a  single  CPU,  it  is  essentially  divorced  from  the  underlying 
implementation  hardware  architecture.  Tlie  second  topic  is  on  the  distribution  of  Ada 
programs  for  loosely  coupled  multiprocessors.  This  aspect  of  the  project  has  been  an  area  of 
considerable  debate  which  is  unlikely  to  subside  until  several  implementations  resolve  the 
issues.  Unlike  tightly  coupled  processors,  loosely  coupled  processors  incur  significant 
oveihead  in  inter-processor  communication.  For  this  reason,  it  has  been  questionable 
whether  or  not  the  tasking  semantics  of  Ada  can  be  (or  should  be)  implemented  for  use  on 
real-time  systems.  This  section  discusses  many  of  the  critical  issues  in  using  the  Ada  model 
of  con<;'!irftncy  across  a  network  and  provides  ihe  implementation  st;  ucgy  used  on  the 
demonstration  project. 

2.  Demonstration  Application 

The  demonstration  application  was  chosen  among  three  proposed  candidates. 

1)  Attitude/ Altitude  Control  for  remote  controlled  helicopter  (RPV) 

2)  Vision-based  sentry  system  to  perform  guard  duty 

3)  A  weapon  system  to  intercept  attacking  armor 

Ihe  first  candidate  was  rejected  because  the  risk  associated  with  the  mechanics  of  the 
system  affecting  the  success  of  the  project  was  deemed  to  be  unacceptable.  The  third 
candidate  was  selected  over  the  second  candidate  because  it  seemed  to  have  greater 
similarity  to  a  majority  of  DoD  applications,  and  because  of  more  severe  real-time 
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requirements.  The  selected  system  was  titled  the  "Border  Defense  System  (BDS)"  and  is 
designed  to  provide  short  to  medium  range  protection  against  a  massive  armored  attack. 


The  complete  requirements  for  the  BDS  are  contained  in  Appendix  A,  however  the  main 
characteristics  are  summarized  below: 


-  Hard  Deadline  Driven  application:  failure  to  meet  timing  requirements  will  result  in 
total  mission  failure. 

-  "Processor  in  the  Loop"  flight  control  with  dynamic  target  tracking. 

-  Complex  problem,  with  interaction  among  several  different  functional  areas; 

Message  Reception  (from  Sensor  Interface  and  Airborne  Rockets) 

Target  Tracking  and  Prediction  (up  to  100  simultaneous  targets) 

Rocket  Tracking  and  Guidance  (up  to  20  simultaneous  rockets,  rockets  travel  at 
supersonic  velocities  and  are  guided  by  updates  every  lOOms) 

Real-Time  Graphics  Updates 

Real-Time  Operator  Interface  (Mouse  peak  data  rate  of  500Hz) 

Message  Transmission  (to  Rockets  and  Rocket  Launcher) 


-  Using  current  technology:  32-bit  Microprocessors  (80386-16MHz) 

-  A  separate  program  was  designated  for  the  simulator  initially,  however  the 
simulation  portion  of  the  project  was  incorporated  into  the  system  as  additional  tasks 
and  placed  on  a  separate  processor  using  the  distribution  technique. 

-  Less  than  1.0%  "code"  statements.  No  assembly  language  allowed. 

-  All  application  concurrency  is  expressed  using  the  Ada  Tasking  Model  (Rendezvous) 
exclusively. 

-  The  program  consists  of  approximately  3200  Ada  LOG,  of  which  26  are  Inlined  code 
statements.  It  is  divided  into  31  library  units  or  subunits,  and  contains  12  tasks  (1 
interrupt  entry). 

2.1  Design  Method 
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The  selected  design  approach  uses  an  iterative  technique  to  refine  the  system  and  software 
design.  It  is  Time/Risk  Driven  to  address  the  areas  that  are  perceived  most  difficult  first. 

A  key  component  of  the  method  is  to  prototype  those  algorithms  that  are  known  to  be 
required  in  the  system,  yet  their  execution  time  is  difficult  to  accurately  estimate.  The 
resulting  prototype  data  is  used  to  develop  timing  budgets  and  design  a  software  structure  to 
insure  correct  timing.  Emphasis  is  placed  on  meeting  (software)  deadlines  first,  and  to  get 
the  exact  functionality  later.  (However  functionality  must  be  sufficiently  correct  to  model 
the  timing  accurately.)  This  approach  is  driven  by  the  (unpleasant)  experience  that  it  is  often 
much  easier  -to  "fix"  the  functionality  than  the  performance.  Put  another  way,  it  can  be 
extremely  difficult  to  improve  the  performance  of  a  system  that  is  grossly  out  of 
specification.  Systems  that  are  initially  5  to  20  times  too  slow  are  not  uncommon,  and 
frequently  result  in  complete  redesign.  This  places  timing  on  top  of  the  RISK  list.  Where 
the  functionality  of  some  processing  is  not  well  understood,  these  are  also  appropriate  areas 
to  prototype.  Prototypes  may  be  utilized  in  the  final  product  providing  that  they  are 
upgraded  to  insure  compliance  with  coding  styles.  The  process  associated  with  the  design 
method  used  is  described  as  the  Ada  Time  Oriented  Method  (ATOM). 

It  should  be  noted  that  one  possible  drawback  of  any  iterative  technique  is  the  confusion 
that  can  occur  in  the  minds  of  the  designers/implementers  with  the  different  variations  on 
the  design.  Care  must  be  taken  not  to  "brainstomt"  at  the  implementation  level  for  fear  of 
mass  confusion  resulting.  The  degree  to  which  a  clear  state  of  the  system  design  can  be 
conveyed  (either  graphically  or  textually)  dictates  the  freedom  with  which  designs  may 
evolve.  To  ignore  the  nature  of  humans  to  confuse  very  similar  designs  by  getting  details 
transposed  in  their  minds,  is  a  prescription  for  long  integration  cycles. 


2.2  Ada  Hme  Oriented  Method  (ATOM) 
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This  software  design  technique  is  targeted  for  hard  real-time  embedded  applications,  where 
the  most  difficult  aspect  of  the  project  is  meeting  the  timing  requirements.  In  these 
applications,  the  correct  functioning  of  the  system  depends  on  proper  timing  as  much  as  the 
correctness  of  the  calculations.  This  method  may  not  be  appropriate  for  applications  that  do 
not  have  a  significant  real-time  component. 

For  the  following  steps  in  the  method,  the  term  "message"  simply  refers  to  an  I/O 
transaction  of  any  type.  It  may  be  a  single  byte,  or  a  complex  transfer  of  data  items. 


Step  1;  List  the  modes  in  which  the  system  operates  that  result  in  different  flow  control 
and/or  timing  requirements. 

Step  2;  For  each  mode,  determine  all  input/output  requirements  of  the  system.  List  all 
messages  with  their  sizes,  average,  typical,  and  worst  case  periods. 

Step  3:  List  the  events  that  have  fecial  timing  relationships.  Generate  a  chart  of  events 
showing  their  relationships  (Event  Timing  Relationships  •  ElR). 

Step  4;  For  each  message,  indicate  what  event  invokes  generation  of  the  message. 


Step  5:  Develop  a  test  plan  to  detect  and  record  events  that  meet  the  system  requirements. 
(Thinking  about  how  to  test  the  software  is  an  essential  part  of  the  design). 

Step  6:  For  each  message,  indicate  what  function(s)  is(are)  required  to  process  it. 

Step  7;  List  all  temporallv  related  messages  together.  These  are  messages  that  can  be 
processed  sequentially  without  intervening  delays.  Distinguish  between  those  that  can  be 
processed  sequentially  from  those  that  must  be  processed  sequentially. 

Step  8:  Allocate  the  processing  of  messages  to  tasks  according  to  message  priority  and 
temporal  relationship.  Pay  speaal  attention  to  deadlines. 

Step  9:  Assign  priorities  to  tasks,  dictated  by  the  priority  of  the  messages  in  the  task. 
Highest  priority  tasks  will  typicalljf  be  associated  with  hardware  interrupts.  Insure  that  the 
hardware  supports  the  interrupt  priorities  dictated  by  the  design. 


Step  10:  Produce  high  level  PDL  indicating  the  functions  called.  Use  packages  to  combine 
logically  related  objects  and  to  provide  isolation  from  those  that  are  disjoint,  use  functional 
decomposition  to  provide  additional  detail.  Provide  the  greatest  detail  for  those  areas  that 
are  most  likely  to  unpact  the  performance  of  the  system. 


Step  11:  Develop  threads  based  on  the  individual  paths  within  each  task. 
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Step  12:  Document  assertions  made  in  order  to  ^arantee  the  required  timing.  For 
‘Example:  "High  Priority  Task  A  will  only  preempt  Task  B  once  per  20ms,  and  for  a  time  less 
than  3ms  in  length."  Maintain  a  data  base  oi  all  assertions  that  are  related  to  external 
interfaces. 

Step  13:  Produce  static  timing  budget  of  each  path  segment,  using  "best  estimates".  Build  a 
model  based  on  threads  and  timing  data  to  compute  processor  utilization. 

Step  14:  For  execution  time  estimates  that  are  uncertain,  order  them  in  tenns  of  greatest 
risk. 

Step  15:  Starting  at  the  top  of  the  UNCERTAIN  list,  prototype  each  segment  to  determine 
actual  time  of  execution. 

Step  16:  Feed  actual  times  back  into  the  timing  budget  and  recalculate  processor  utilization 
with  the  model. 

Step  17:  Model  event  activity  and  compare  against  requirements. 

Step  18:  Develop  a  worst-case  (or  several  worst-case)  scenarios  that  can  be  used  to  test  the 
system  for  meeting  the  difficult  timing  requirements.  These  should  be  used  to  convey  the 
scope  of  the  real-time  concerns  to  the  individuals  writing  thi;  software  code. 

As  new  I/O  and  Events  are  added  to  the  system  (because  of  mid-course  design  changes  or 

because  of  previous  oversight),  iterate  on  the  above  steps  to  maintain  proco.':scr  utilization 

and  response  time  metrics.  Using  this  information,  intelligent  decisions  can  be  made 

regarding  the  efficiency  of  code  required.  The  process  steps  above  should  be  automated  to 

the  greatest  extent  possible  so  as  to  facilitate  design  changes,  and  to  allow  exploration  of 

alternatives.  A  sample  timing  budget  is  shown  in  Appendix  G. 


The  general  philosophy  should  be  to  always  have  a  spectrum  of  choices  to  select  from  that 
provide  increasing  performance,  at  the  sacrifice  of  memoiy,  complexity,  and  ease  of 
maintenance.  By  knowing  the  difficulty  of  the  real-time  aspect,  the  program  can  be  written 
to  maximize  maintainability  while  still  meeting  the  performance  objectives.  A  program  that 
is  maintainable  but  does  not  function  because  of  performance  problems  is  just  as  useless  as  a 
program  that  functions  but  is  not  maintainable.  Both  objectives  are  essential. 


23  Testing 
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The  design  should  incorporate  testability  as  an  essential  requirement.  It  should  be  assumed 
that  if  the  system  can  not  be  tested,  then  it  does  not  work.  Furthermore,  mechanisms  must 
be  provided  to  allow  logging  of  software  faults  whenever  this  is  feasible.  Experience  has 
shown  that  real-time  systems  frequently  fail  under  actual  conditions,  when  they  did  not  fail 
under  nearly  identical  conditions  in  the  lab.  This  necessitates  being  able  to  provide  some 
useful  system-state  information  at  the  point  of  failure  so  that  some  insight  is  provided  to  the 
maintenance  engineers. 

Testing  should  be  done  in  a  way  that  makes  automatic  regression  testing  possible.  That  is, 
command  files  should  be  established  for  the  testing  of  each  CSC  (Computer  Software 
Component)  down  to  the  unit  level  such  that  the  suite  of  tests  can  be  run  in  a  fully  automatic 
mode.  Command  files  on  the  development  host  will  place  the  simulator  system  into  a 
predefined  state,  initiate  the  executable  image  on  the  target  and  collect  the  results  of  the 
test.  When  necessary,  breakpoints  may  be  set  using  command  files  for  the  debugger.  Source 
lines  that  will  require  a  breakpoint  should  have  a  test  point  comment:  "-TPJcax"  where  xxxx 
is  a  4-digit  decimal  number  identifying  a  unique  test  point.  The  automatic  test  procedures 
(command  files)  should  reference  test  point  numbers,  and  will  be  machine-translated  to  line 
numbers  by  a  TEST_POINTS  tool.  At  a  minimum,  each  testable  requirement  specified  in 
the  Software  Detailed  Design  Document  (SDDD)  should  be  verified  in  a  test.  Additional 
tests  should  be  written  as  necessary  to  improve  the  reliability  of  the  software. 

2.4  Prototype  Issues 

During  the  development  of  the  prototypes,  several  problems  were  encountered  that  required 
design  decisions.  The  critical  areas  that  required  prototyping  were  enumerated  as: 
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Graphics  Display  Updates 
Communications  Driver 
Rocket  Guidance  Calculations 
Operator  Interface  (Mouse) 

2.4.1  Graphics 

The  graphics  updates  entailed  placing  target  symbols,  rocket  symbols,  and  the  targeting 
reticle  [cross  hairs]  on  the  screen  fast  enough  so  that  any  perceptible  motion  was  not  lost 
due  to  processing  overhead.  With  such  a  large  number  of  targets  and  rockets  moving,  the 
number  of  screen  updates  is  significant.  Essentially,  1235  screen  updates  must  be  done 
every  second,  which  allows  a  maximum  of  810  microseconds  per  update  (assuming  100% 
CPU  utili-^ation).  An  update  consists  of  erasing  and  redrawing  a  symbol  containing  beriveen 
6  and  j3  pixels.  Initial  software  took  advantage  of  standard  software  supplied  by  the 
graphics  interface  manufacturer  to  draw  the  symbols.  Timing  measure)  neats  iiidi':ated  that 
it  took  well  over  a  millisecond  to  draw  a  simple  symbol.  As  a  result,  it  was  necessary  to 
scrap  the  vendor  supplied  routines,  and  provide  a  more  customized  interface  that  provided 
better  performance.  Although  the  rockets  travel  fast  enough  so  that  they  cross  a  pixel 
boundary  (move)  every  100ms,  the  targets  often  will  not  move  every  update  (100ms).  It  is 
possible  to  significantly  reduce  the  processing  time  by  taking  advantage  of  this  fact,  however 
it  is  still  possible  for  all  100  targets  to  cross  a  pixel  boundary  during  a  single  update  period. 
This  worst  case  must  be  taken  into  account  From  an  operator's  point  of  view,  it  will  not 
matter  if  some  targets  are  deferred  into  the  next  update  period,  so  if  the  software  can  ride 
through  this  "overload"  condition  for  one  update,  it  is  possible  to  reduce  the  worst  case 
processing  requirement  nearly  in  half. 
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The  machine  code  statements  are  used 'to  implement  the  Put  Pixel  procedure.  This 
procedure  performs  bit  manipulations  that  could  not  be  achieved  with  the  Ada  code 
generator,  and  were  required  for  every  pixel  displayed  (or  erased)  on  the  screen.  Variable 
shifts  were  required  to  select  the  appropriate  bit  to  set  or  clear.  Although  the  same  effect 
can  be  approximated  with  divide  or  multiply  instructions,  the  execution  time  is  one  seventh 
as  long  when  using  the  shift  instruction. 

2.4.2  Communications  Driver 

The  communications  driver  must  process  at  least  30  messages  per  second.  After  the  design 
change  to  incorporate  the  Simulator  into  the  BDS  program,  these  communications  occur  as 
rendezvous  operations.  They  are  performed  by  the  extended  runtime  that  supports 
distributed  Ada,  and  use  buffer  queues  maintained  within  the  runtime.  Direct  access  to  the 
network  is  not  provided  to  the  application  program.  If  the  simulator  is  redeveloped  as  a 
separate  Ada  program,  it  can  either  emulate  the  rendezvous  protocol  or  the  BDS  can  be 
modified  to  provide  the  communications  with  an  Ada  task  serving  as  the  interface  driver.  In 
this  case,  the  low  level  interaction  with  the  Ethernet  hardware  will  be  shared  by  the 
distributed  runtime  and  the  application  program. 

2.4.3  Rocket  Guidance 

Rocket  guidance  calculations  proved  to  be  quite  time  consuming.  Initial  attempts  at  using 
Ada  fixed  point  calculations  led  to  frustration  due  to  the  fact  that  on  one  compiler  used, 
fixed  point  was  being  emulated  using  floating  point  Fortunately  the  production  compiler 
supported  fixed  point  in  a  more  efficient  manner.  Previous  experience  had  provided 
warning  that  it  was  difficult  to  get  fixed  point  numbers  with  a  ’small  that  is  not  a  power  of 
two  (most  implementations  restrict  representation  clauses  on  4X’small  to  a  power  of  two) 
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Ther^;foi’e,  it  was  imposed  on  the  system  design  that  the  hardware  provided  all  dimensions 
as  a  power  of  two  value.  For  example,  the  METERS  type  used  to  provide  battlefield 
position  had  a  delta  of  0.125. 

Several  application  dependent  optimizations  were  implemented  to  radically  reduce 
computation  time.  For  example,  since  accuracy  became  very  important  as  the  rocket 
approached  the  target,  it  was  possible  to  take  advantage  of  the  fact  that  the  target  could  not 
move  significantly  dujing  the  final  ingress  phase  of  flight.  Normally  the  motion  of  the  target 
must  be  accounted  for  in  any  targeting  system,  but  since  the  BDS  recomputed  target  position 
every  100ms,'  a  simple  forward  extrapolation  provided  sufficient  accuracy  to  guarantee  a 
"hit".  This  replaced  a  more  complex  iterative  algorithm  which  was  used  to  compute  the 
angle*to-intercept  values. 

Furthermore  the  tangent  function  was  replaced  with  a  lookup  table,  the  arc  tangent  function 
with  a  rough  appro.'dmation  function,  and  the  square  root  function  was  <]esigned  to  run  in 
acceptable  worst-case  time,  with  better  accuracy  at  closer  ranges. 

2.4.4  Operator  Interface 

•The  mouse  interface  has  turned  out  to  be  one  of  the  more  critical  components  of  the  system. 
Early  tests  indicated  that  poor  response  time  on  the  mouse  resulted  in  erratic  movement  of 
the  targeting  reticle.  This  made  it  nearly  impossible  to  lock  on  a  target  and  would  result  in 
mission  failure  in  a  target-rich  environment.  Another  aspect  about  the  mouse  interface  that 
makes  it  complex  is  the  limited  hardware  support  for  the  mouse.  Only  a  single  byte  buffer  is 
supplied  for  incoming  data.  This  translates  to  a  lost  message  if  bytes  are  not  read  by  the 
application  software  prior  to  the  next  byte  reception  (2  ms).  An  interrupt  task  is  used  to 
accept  the  data  and  buffer  it  for  display  processing.  Care  is  required  to  prevent  the  high 
priority  mouse  task  from  being  suspended  while  display  processing  was  in  progress. 
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The  BDS  source  code  is  listed  in  appendix  H  along  with  the  interface  design  documents  and 
simulator  specifications  in  appendices  B  through  E.  A  graphical  overview  of  the  top  level 
BDS  design  appears  in  Figure  1. 
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Figure  1.  Top  Level  BDS  Design 
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3.  Compiler  and  Language  Problems  Encountered 

Currently  the  "extended"  features  of  Ada  are  not  widely  used,  and  therefore  have  the 
greatest  number  of  latent  anomalies.  They  should  be  carefully  tested  during  integration  to 
determine  their  reliability.  Note  that  the  vendor  was  contacted  for  a  list  of  "known" 
anomalies,  and  they  indicated  that  no  such  list  was  available.  In  fairness  to  the  compiler 
vendor,  their  product  is  believed  to  be  the  most  advanced  Ada  compiler  of  its  kind.  It  is  a 
comment  on  the  complexity  of  real-time  systems  that  there  are  still  many  problems  with  the 
Ada  compilers.  The  runtime  executives  are  attempting  to  solve  many  of  the  issues  of 
real-time  programming  and  need  to  be  extremely  robust,  yet  fast.  These  are  two  aspects  that 
generally  work  against  each  other. 

1)  L0NG_F1XED  division  was  unreliable.  Certain  numbers  (resulting  in  bit  patterns  very 
close  to  IFFFFh)  caused  divide  error.  This  manifested  itself  by  causing  a 
NUMERIC^ERROR  after  hours  of  operation  and  hundreds  of  rocket  launches  and  target 
intercepts. 

2)  Improper  Inlining  of  code  statements.  If  the  last  instruction  of  the  calling  sequence  used 
the  same  register  as  the  first  instruction  of  the  machine  code  procedure  to  be  inlined,  the 
code  generator  would  exchange  the  two  instructions: 


mov  Cbp-10],cx 

mov  cx, Cbp-20]  codt  ststemtnt  begin 


would  becoim: 

MOV  cx, (bp- 201 

MOV  [bp-IOl.cx  --  reorder,  resulted  in  storing  of  incorrect  value 

Note  that  this  problem  appeared  after  the  code  in  question  had  already  undergone 
successful  integration  testing.  It  appeared  suddenly  after  a  new  re-compilation  caused 
different  registers  to  be  used  (with  no  changes  in  compiler  switches). 
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3)  If  an  interrupt  occurs  when  the  auto-increment  direction  flag  is  set,  it  is  not  restored 
properl>  if  the  interrupt  is  handled  by  an  Ada  task  (using  the  INTERRUPT_HANDLER 
pragma)  which  makes  an  entry  on  another  task.  This  only  appeared  when  the  system  w  as 
heavily  loaded,  and  periodic  rates  were  set  to  the  full  speed.  Fortunately  the  one  place  in 
the  code  where  the  direction  flag  is  set  (normally  it  is  cleared)  was  exeaited  quite  frequently 
so  the  problem  could  be  reproduced,  although  not  in  a  predictable  fashion. 

4)  Complex  expressions  did  not  generate  the  correct  code  sequence.  Actual  parameters 
containing  array  aggregates,  which  in  turn  consisted  of  multidimensional  array  references 
with  non-integer  subscripts  resulted  in  a  failure  for  the  appropriate  segment  register  to  be 
loaded  correctly.  The  graphics  task  takes  a  parameter  list  consisting  of  the  old  and  new 
positions  of  an  object(x,y),  the  object  type  (rocket,target,  etc.),  and  a  color.  To  determine 
Lihi  color,  an  array  indexed  by  the  object  type  u)  one  dimension  and  a  status  flag  indicating  if 
it  was  engaged  for  intercept  wj\s  used  in  the  other  dimension.  This  causes  target:  to  "light 
up"  when  engaged  for  intercept.  However,  it  did  not  work  and  the  code  was  rewritten  to 
create  temporaries  during  each  step  of  the  expression.  The  failure  mode  was  to  select  the 
zero(O)  color  -  black,  which  gave  the  appearance  that  nothing  was  working,  when  in  fact 
invisible  targets  were  moving  on  the  screen. 

5)  The  pragma  to  establish  task  storage  size  did  not  function.  This  resulted  in  the  program 
terminating  before  initial  elaboration  was  complete.  Basically  the  program  would  simply 
crash  with  no  exception  trace  back  (due  to  the  fact  that  the  program  had  not  completed 
elaboration).  This  required  a  programmer  to  single-step  through  the  code  to  find  where  the 
problem  was.  Tl]e  solution  was  to  use  a  linker  option  to  set  the  library  stack  size,  which  did 
work  although  it  applied  the  same  stack  size  for  all  library  tasks.  A  general  comment  is  that 
it  is  extremely  difficult  to  determine  the  correct  size  required  for  a  task  stack.  Ideally  an 
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automatic  approach  to  setting  the  stacks  ^ould  be  supported.  It  might  use  pragmas  to 
provide  maximum  call  depth  information  to  the  compiler.  The  compiler  could  compute  the 
worst  case  storage  requirement  for  each  task  type  and  allocate  their  stacks  accordingly. 

6)  Deeply  nested  exceptions  did  not  propagate  properly.  In  a  task,  a  loop  with  an  exception 
block  called  a  procedure  which  had  an  exception  and  no  exception  handler.  The  exception 
should  have  propagated  to  the  exception  block  within  the  loop  (which  had  an  "others" 
clause),  but  instead  propagated  to  the  outermost  level  of  the  task,  causing  it  to  terminate 
silently.  Debug  trace  statements  were  placed  in  each  of  the  tasks  but  these  were  not  invoked 
when  exceptions  occurred.  The  result  was  either  a  deadlock,  or  other  tasks  getting 
TASKING_ERR0R  when  rendezvous  were  attempted. 

7)  Package  Calendar  elaboration  check  was  not  performed  properly.  A  number  of  problems 
with  elaboration  were  encountered  (due  to  library  tasks  starting  execution  before  other  units 
are  elaborated).  One  strange  problem  was  due  to  the  fact  that  no  elaboration  check  was 
performed  prior  to  calling  the  Calendar.Clock  function  to  establish  the  periodic  start  point. 
Apparently  the  Calendar  package  body  had  not  been  elaborated  and  the  Qock  function 
returned  the  time  of  a  few  hundred  microseconds  into  mission  time.  Then  after  the  calling 
task  was  suspended  for  a  rendezvous,  the  Calendar  package  was  elaborated,  which  set  the 
TIME  value  to  some  time  in  1987  (a  very  large  number).  When  the  task  resumed  execution, 
it  reached  the  end  of  its  loop  and  attempted  to  compute  the  delay  necessary  to  achieve  the 
desired  interval.  Since  the  delta  time  was  almost  2000  years,  it  exceeded  the  range  of 
duration  and  a  NUMERIC_ERROR  was  raised  (although  a  TIME_ERROR)  should  have 
been  raised. 

8)  Calling  more  than  a  single  entry  from  within  an  interrupt  task  (using  pragma 
INTERRUPT_HANDLER)  can  result  in  a  system  crash.  Using  the  rendezvous  to  signal  a 
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background  task  to  continue  execution  is  essential  in  real-time  applications.  This 
mechanism  may  not  be  reliable  on  all  implementations  and  special  precautions  are 
necessary  for  its  use. 

9)  Named  associations  in  aggregates  generated  substantial  amounts  of  additional  runtime 
code  over  using  simple  positional  associations.  This  was  true  even  if  the  values  were 
positionally  correct  as  well.  This  resulted  in  having  to  limit  the  named  associations  and  to 
put  the  names  in  comments  foUowing  the  statements.  This  had  a  negative  impact  on  the 
readability  of  the  program. 

The  impact  of  having  many  failures  in  the  runtime  and  generated  code  is  demoralizing  on 
the  engineering  staff.  It  becomes  apparent  that  the  most  difficult  problems  to  find  are  those 
of  ^he  runtime  and  generated  code,  since  one  expects  the  Ada  statements  to  work  as 
specified.  Tnere  is  a  realization  that  the  success  of  the  project  is  out  of  your  hands,  and  in 
the  hands  of  the  compiler  vendor.  No  matter  how  good  the  engineering  team  is,  the  system 
will  not  work  if  the  translation  from  source  to  the  generated  code  is  incorrect.  This  is 
unusual  for  real-time  programmers  who  are  familiar  with  assembly  language,  where  there 
are  far  fewer  discrepancies.  When  discrepancies  do  exist,  they  are  much  easier  to  find. 

Finally,  a  problem  that  surfaced  with  the  Ada  language  was  a  standard  way  to  provide 
atomic  transactions  that  could  cross  the  application  code  to  runtime  code  boundary.  The 
application  has  a  requirement  to  accept  frequent  interrupts,  buffer  the  data  to  a  certain 
point  (based  on  the  input  stream),  and  then  perform  a  considerable  amount  of  processing  on 
the  data,  while  new  data  is  arriving.  This  is  done  by  having  an  interrupt  task  perform  the 
buffering,  then  passing  the  data  off  to  a  background  task.  The  difficulty  is  that  the  interrupt 
task  may  not  be  suspended  (for  any  reason  other  than  to  service  higher  priority  hardware 
interrupts).  This  implies  that  a  conditional  rendezvous  is  required.  However,  what  is  really 
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required  is  the  ability  to  queue  the  buffer  and  request,  then  signal  the  background  task  if  it  is 
suspended  waiting  for  new  data.  Essentially  there  are  two  approaches  to  this  problem:  1) 
provide  a  suffident  number  of  buffer  tasks  so  that  they  can  act  as  surrogates  on  the  entiy 
queue  of  the  background  task,  or  2)  maintain  a  flag  that  is  only  set  when  the  buffer  task  is 
ready  to  immediately  accept  a  rendezvous.  This  requires  that  the  background  task  disable 
any  type  of  preemption;  check  if  there  is  more  work  to  do;  and  if  not,  perform  the  accept 
statement.  Presumably  the  runtime  will  then  allow  preemption  only  after  placing  the 
background  task  in  a  position  to  immediately  accept  the  rendezvous.  The  interrupt  task 
obviously  will  not  attempt  a  rendezvous  with  the  background  task  unless  the  flag  is  set.  Both 
of  these  solutions  have  serious  drawbacks.  The  surrogate  task  approach  requires  substantial 
optimization  on  the  part  of  the  compiler  and  runtime.  Furthermore,  it  may  obfuscate  the 
intent  of  the  rendezvous.  The  second  approach  is  very  implementation  dependent,  and  is 
prone  to  error  if  used  by  other  than  very  experienced  and  careful  programmers.  What  is 
clearly  needed  is  an  asynchronous  form  of  task  communication.  This  could  return  to  the 
language  as  revised  forms  of  the  "SEMAPHORE"  and  "SIGNAL"  generic  tasks  defined  in 
the  "Preliminary  Ada  Reference  Manual"  [3]  .  Although  an  argument  can  be  made  that 
implementations  can  provide  the  same  effect  as  these  predefined  task  types,  to  depend  on 
implementation  optimizations  for  such  crucial  real-time  operations  is  a  questionable  design 
approach. 

4.  Hardware  Problems  Encountered 

Several  hardware  problems  were  encountered  during  the  development  of  the  BDS  system. 
For  the  most  part,  they  presented  minor  nuisances,  but  in  some  cases  resulted  in  days  of 
additional  testing  to  isolate  the  problem. 
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One  of  the  'five  Ethernet  cards  used  arrived  non-ftinctioning.  After  approximately  one*half 
hour  of  performing  various  tests,  the  failure  was  isolated  to  a  bad  "station  address  PROM". 
This  nonvolatile  memory  holds  a  unique  network  address  for  communication  on  the 
Ethernet.  Upon  very  close  inspection  of  the  PROM  integrated  circuit,  it  was  noticed  that 
one  of  the  pins  had  been  bent  under  the  chip.  By  removing  the  chip,  straightening  the  bent 
pin,  and  reinserting  the  chip,  the  problem  was  solved  in  a  few  hours. 

Trie  80386  computer  card  has  a  VLSI  chip  (80C206)  used  to  control  interrupts,  timers,  and 
several  other  features  in  the  computer.  One  reature  that  was  used  to  obtain  accurate  clock 
values  was  a'  mode  which  latches  the  two  bytes  of  the  16-bit  counter  as  well  as  a  status 
register  simultaneously.  This  is  necessary  because  the  counter  is  changing  value  every  418 
nanoseconds  and  getting  reliable  values  is  difficult  without  such  a  latch.  Unfortunately,  the 
latcn  did  net  work.  The  programming  of  these  chips  is  extremely  complex,  and  the  first 
assumption  when  something  fails  is  to  suspect  the  software  that  interfaces  to  the  chip.  The 
documentation  was  rather  vague,  and  as  a  result  approximately  two  days  were  lost  until  it 
was  concluded  that  the  chip  may  be  bad.  Note  that  the  timers  worked  fine,  and  the  rest  of 
the  chip’s  thousands  of  transistors  apparently  worked  fine  as  well,  so  hardware  failure  was 
not  suspected.  The  only  failure  symptom  was  that  once  in  a  great  while,  a  time  would 
appear  to  jump  backward  by  a  small  dc-.-rement.  This  was  due  to  reading  one  byte  while  the 
status  of  the  other  bytes  changed.  By  trying  the  exact  same  software  on  another  computer,  it 
was  determined  that  there  was  indeed  at  least  one  bad  gate  on  the  30C206  chip.  A 
replacement  chip  was  ordered  and  when  it  arrived,  it  did  not  work  at  all.  A  month  later  the 
second  replacement  chip  did  work,  and  solved  the  timing  problems. 

Although  not  strictly  a  hardware  failure,  the  documentation  describing  the  Ethernet 
hardware  had  numerous  errors.  Wwks  were  spent  trying  different  initialization  sequences 
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in  an  attempt  to  debug  the  network  drivers.  For  example,  the  board  has  an  on-board 
network  transceiver,  and  may  alternatively  use  an  externally  supplied  transceiver.  The  bit 
that  controls  which  transceiver  is  used  was  incorrectly  specified  in  the  documentation.  It  was 
pretty  much  an  act  of  desperation  that  allowed  the  error  to  be  found. 

Likewise,  the  technical  manual  on  the  mouse,  incorrectly  specified  jumper  settings  which 
establish  the  communication  protocol  between  the  mouse’s  processor  and  the  BDS 
processor.  Once  again,  it  was  trial  and  error  until  something  worked,  and  the  error 
condition  could  be  verified. 

5.  Distributed  Ada 

Note  that  while  multiprocessing  may  be  used  to  help  solve  the  performance  problem 
assodated  with  Ada,  it  is  not  a  cure-all.  Developing  software  using  ineffident  algorithms 
and  then  trying  to  apply  a  large  number  of  processors  in  order  to  get  the  desired 
performance  is  not  suggested  as  an  appropriate  design  method.  Suitable  algorithms  can 
make  a  much  more  significant  impact  on  performance  than  adding  several  processors.  The 
additional  processors  should  be  regarded  as  a  fine  adjustment  on  the  performance  rather 
than  a  simple  multiplier.  This  is  dictated  by  the  fact  that  the  recurring  cost  of  hardware, 
while  continuing  to  fall  on  a  cost/performance  basis,  is  still  not  inconsequential.  While 
adding  another  processor  cannot  compensate  for  poor  software,  it  can  more  than 
compensate  for  some  effidency  lost  because  of  immature  compiler  technology.  If  the  high 
level  language  can  take  the  complexity  out  of  the  distribution  effort,  then  the  result  is  a 
system  that  will  perform  better  and  cost  less  over  the  life  of  the  system. 

5.1  Definition  of  Terms 
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The  term  "Distributed  Processing"  is  frequently  used,  and  often  with  meanings  that  imply 
radically  different  architectures.  For  this  reason,  the  use  of  the  term  within  this  paper  is 
explicitly  stated. 

Distributed  Processing,  for  the  purposes  of  this  project,  shall  be  defined  as:  "a 
multiprocessor  system  characterized  by  having  communicating  autonomous  processors, 
where  the  communication  response  and  throughput  are  significantly  lower  than  local 
memory  access". 

"Significantly"  in  the  above  sentence  implies  a  difference  that  is  greater  than  an  order  of 
magnitude.  The  essential  aspect  of  this  definition  is  the  recognition  that  program 
performance  of  these  systems  may  be  radically  altered  by  changes  in  configuration.  In 
particular,  when  functions  that  interact  within  a  processor  become  separated  onto  two  or 
more  processors,  the  communication  overhead  can  be  dramatic.  Therefore,  in  general, 
relate'’  functions  separated  by  a  processor  boundary  tend  to  be  loosely  coupled  with  each 
other. 

5.2  Project  Objectives 

One  of  the  principle  project  objectives  is  to  determine  how  Ada  tasking  can  be  used  on  a 
distributed  system  to  improve  total  system  performance.  There  are  many  advantages  to 
using  the  Ada  tasking  model  as  the  sole  abstraction  of  concurrency.  Among  them  are: 

1)  The  ability  of  the  compiler  to  check  interfaces  between  physical  processors. 

2)  A  consistent  approach  to  parallelism  ~  all  concurrent  activities  are  expressly  stated  with 
a  consistent  formal  mechanism  making  the  ^stem  less  complex. 

3)  Re-configuration  is  facilitated,  since  the  interface  between  communicating  tasks  on  a 
processor  is  the  same  as  that  among  separate  processors,  thus  allowing  tasks  to  be 
migrated  more  easily. 
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4)  Consistency  helps  to  make  distributed  testing  and  debugging  more  easily  supported  by 
compiler  implementers.  Ad  hoc  approaches  make  debugging  tools  prohibitively 
expensive. 

Several  studies  have  implied  that  the  synchronous  rendezvous  required  by  Ada  is  not 

practical  for  real-time  distributed  systems  [report  to  Real  Time  workshop  at  IDA,  July 

1988].  This  conclusion  is  drawn  because  of  the  communication  required  by  the  Ada 

semantics  creates  tremendous  overhead  in  the  network-based  systems  studied.  Typical 

round-trip  communication  times  were  measured  at  20ms  for  a  single  message/acknowledge, 

of  which  several  might  be  required  for  Ada’s  rendezvous  semantics.  These  numbers  were 

presented  as  being  processor,  operating  system,  and  network  independent  The  work  of  this 
* 

project  implies  that  the  message  transfer  times  are  distorted  in  many  of  these  studies  by  the 
unnecessary  overhead  associated  with  message  presentation  to  the  network.  In  every  case, 
an  intervening  operating  system  such  as  UNIX  or  iRMX86  is  used  rather  than  direct 
interaction  of  the  runtime  with  the  network  interface.  These  operating  systems  do  not 
provide  high  performance  pathways  for  user  programs  to  access  network  facilities. 
Overhead  is  incurred  by  requiring  a  context  switch  between  User  and  Privileged  mode,  and 
often  a  full  process  switch  for  every  message  transmission/reception. 

Furthermore,  additional  network  protocols  such  as  TCP/IP  are  used,  and  packets  are  often 
manipulated  by  a  "smart"  network  interface  card  which  results  in  actually  slowing  down  the 
communication.  Studies  done  on  a  previous  project  indicated  that  it  is  possible  (in  a  lightly 
loaded  Ethernet  system  with  commercially  available  hardware  )  to  perform  the  following 
steps  in  under  two  (2)  milliseconds: 


^UNIX  is  a  trademark  of  AT&T 
^iRMX86  is  a  trademark  of  Intel  Corp. 


-20- 


Demonstration  Project  Final  Report 


1)  call  a  procedure  requesting  a  block  (512  bytes)  of  data, 

2)  generate  a  packet  with  the  request  for  data, 

3)  transmit  the  request  across  the  network  to  a  server  processor, 

4)  server  processor  interprets  the  request  (disk  read), 

5)  read  the  data  from  the  disk  (1ms), 

6)  transfer  the  data  back  to  the  requester, 

7)  the  requester  accepts  the  data,  and  is  ready  to  issue  another  request. 

Since  a  2:1  interleave  was  used  on  the  disk,  the  effect  was  to  achieve  the  same  data  rate  from 
the  remote  disk  as  what  was  available  on  a  local  disk  (identical  hardware).  This  is  due  to  the 
fact  that  with  a  2:1  interleave,  there  is  a  millisecond  delay  (actually  980  usee)  between 
reading  one  disk  sector  and  the  next.  The  disk  is  formatted  this  way  to  allow  the  operating 
system  enough  time  to  read  the  next  sector  before  it  is  mi:sed  and  a  full  rotation  is  required. 
Tlie  developed  software  was  able  to  perform  the  two  way  communication  across  the  network 
during  the  980  microsecond  inter-sector  delay  with  enough  time  left  ovei  to  setup  for  the 
next  operation.  The  software  overhead  associated  with  the  network  was  under  380 
microseconds,  since  the  actual  transfer  time  on  the  network  for  a  512-byte  packet  and  a 
64-byte  packet  was  approximately  600  microseconds. 

The  point  in  the  discussion  above  is  that  people  may  be  rejecting  distributed  Ada  unjustly. 
Similar  to  the  indictments  of  Ada  that  came  about  with  initial  releases  of  compilers,  the 
initial  studies  of  distributed  Ada  are  based  on  prototype  implementations  and  are  built  in  a 
way  that  is  unlikely  to  be  used  in  a  real-time  system.  It  is  essential  to  accurately  determine 
what  the  penalties  of  a  synchronous  protocol  are  prior  to  rejecting  the  Ada  rendeavous 
model  as  being  unsuitable.  Once  the  requirements  imposed  by  Ada  are  clearly  understood, 
it  may  be  possible  to  support  these  requirements  more  efficiently  in  hardware,  and  thereby 
nearly  eliminate  any  penalty  associated  with  using  the  Ada  tasking  model. 
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One  point  that  cannot  be  ignored  is  the  si/bstantial  difference  in  overhead  associated  with 
various  tasking  combinations.  In  particular,  the  presence  of  an  abort,  timed  entry,  or 
selective  wait  with  either  a  terminate  alternative,  or  a  delay  alternative  greatly  complicate 
runtime  processing.  In  addition,  the  reliability  of  the  network  (transmissions  are  not 
guaranteed)  also  increases  overhead  substantially.  This  project  has  shown  that  a  simple 
rendezvous  in  an  error-free  environment  is  achievable  on  commercially  available  hardware 
in  under  1ms. 

5.2,1  Unit  of  Distribution 

Parallel  systems  research  often  concentrates  on  how  to  achieve  parallel  computation  of  a 
process  that  is  described  in  a  serial  language.  Great  effort  is  applied  to  detecting 
independent  calailations  and  executing  them  on  separate  processors.  Qaims  are  made  that 
the  program  design  must  be  fundamentally  changed  in  order  to  achieve  good  performance 
on  different  parallel  architectures.  Our  findings  are  that,  while  this  is  true  for  the  general 
class  of  computer  programs,  it  is  not  so  typical  of  embedded  applications. 

Embedded  applications,  because  of  their  interaction  with  several  real-world  events,  tend  to 
have  natural  parallel  threads  of  control.  In  fact,  programmers  of  such  systems  often  try  to 
artificially  reduce  the  number  of  parallel  threads  in  their  programs  because  of  the  overhead 
associated  with  switching  between  threads.  In  these  cases,  they  combine  two  or  more 
threads.  For  example,  in  an  aircraft  computer  where  a  response  to  pilot  commands  must  be 
processed  within  50ms,  and  new  inertial  data  is  received  every  40ms,  the  program  might 
check  for  a  new  pilot  command  every  time  the  inertial  data  is  received.  This  combination  of 
threads  insures  that  the  pilot  is  monitored  frequently  enough  to  meet  specification.  The 
result  is  that  the  code  has  been  convoluted  by  the  need  to  achieve  a  low-cost"  context 
switch.  Furthermore,  the  pilot  input  is  being  checked  more  frequently  then  necessary,  and 
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yet  will  still  incur  an  average  20ms  delay.  Ideally  a  separate  task  would  be  created  for  both 
functions,  and  they  would  only  execute  upon  (interrupt  from)  receipt  of  pilot  command  or 
inertial  data.  However,  the  context  switch  associated  with  the  ideal  approach  may  cause  the 
program  to  miss  deadlines  in  the  presence  of  a  large  number  of  pilot  commands. 

With  the  latest  generation  of  Ada  compilers,  this  context  switch  overhead  is  being 
substantially  reduced,  and  therefore  it  is  practical  to  express  "naturally"  parallel  activities  as 
Ada  tasks.  Since  the  expression  of  the  dependencies  of  such  tasks  (paraUel  threads)  are 
clearly  indicated  by  entry  calls  and  accept  statements,  the  program  can  be  distributed  in  a 
straightforward  way,  provided  that  the  semantics  of  the  Ada  tasking  model  are  faithfully 
preserved  for  Ada  rendezvous  and  shared  variables. 

5.  Distribution  Implementation  Details 

1'  0  Distributed  mntime  code  is  composed  of  five  modules:  the  Rendezvous  Services, 
Linkage  Code,  Network  I/O,  Network  Setup,  and  a  small  Vendor  Runtime  Interface. 

The  Distributed  Rendezvous  Services  provided  the  initialization,  remote  elaboration  start, 
remote  entry,  local  entry,  selective  wait  (among  either  local  or  remote  tasks),  remote  start 
accept,  remote  end  accept,  and  local  end  accept.  Additionally,  routines  were  provided  that 
exeojte  at  interrupt  level  to  respond  to  incoming  messages.  These  include:  begin  elaborate, 
end  elaborate,  request  entry,  and  accept  complete. 

The  Linkage  Code  provided  additional  information  such  as  the  length  of  parameters  for  the 
distributed  rendezvous  calls  that  is  not  normally  needed  for  tasks  that  share  memory. 

The  Network  I/O  and  Setup  modules  provided  direct  interface  to  the  Ethernet  hardware. 
All  protocol  management  and  packet  construction  was  performed  by  this  software,  as  well  as 
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direct  initiation  of  packet  transmission  'and  interrupt  response  upon  completion  of 
transmission  or  packet  reception.  Buffers  were  allocated  and  deallocated  from  a  fixed  size 
buffer  pool  for  efficiency.  For  example,  buffer  deallocation  time  was  under  5  microseconds. 

Packets  contained  the  normal  48-bit  destination  and  source  addresses,  a  field  termed 
"receive  control  pointer",  packet  priority,  sequence  number,  and  total  packet  length  followed 
by  parameter  data.  The  receive  control  pointer  (RCP)  was  used  by  the  receiving  processor 
to  determine  how  to  process  an  incoming  message,  which  task  and/or  entry  is  referenced, 
and  to  locate  the  proper  reply  message  header.  Use  of  these  pointers  reduced  the  amount  of 
information  necessary  to  be  transmitted,  and  provided  quick  access  to  statically  created 
packet  headers. 

The  Vendor  Runtime  Interface  module  provided  addresses  for  standard  P  and  V  semaphore 
operations  used  to  "wait"  and  "signal"  task  execution. 

The  distributed  runtime  was  developed  using  assembly  language  to  be  compatible  with  the 
vendor’s  runtime,  and  to  more  accurately  determine  what  could  be  achieved  rather  than 
allow  possible  high  level  language  inefficiencies  from  biasing  the  results.  Future  work  would 
probably  benefit  from  an  Ada  implementation,  and  it  would  be  interesting  to  compare  the 
relative  performance  of  the  two  approaches.  Refer  to  Appendix  I  for  source  code  of  the 
distributed  runtime  code. 

7.  Distribution  Issues 

7.1  Language  Issues 

The  Ada  Standard  provides  a  degree  of  confusion  as  to  what  semantics  are  required  in 
distributed  systems.  Examples  and  possible  solutions  for  these  situations  are: 
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1)  Timed  Entry  Calls  -  The  Ada  language  reference  manual  (RM)  implies  that  the 
rendezvous  will  be  cancelled  if  it  camiot  begin  prior  to  the  delay  specified.  This  leads  to 
confusion  on  a  distributed  system  where  the  delay  may  expire  prior  to  being  able  to  request 
a  rendezvous  with  a  remote  task.  But  the  Ada  semantics  would  have  permitted  the  same 
rendezvous  to  occur  if  the  delay  were  0.0  or  negative,  since  in  this  case  the  semantics  of  the 
conditional  entry  call  are  used.  It  is  pretty  clear  that  the  desired  semantics  are  to  ALWAYS 
attempt  the  rendezvous,  regardless  of  the  delay  specified  (like  a  conditional  call),  and  if  the 
server  is  not  at  a  corresponding  accept,  then  wait  the  specified  delay  prior  to  cancelling  the 
call. 

2)  Package  Calendar  -  Although  no  explicit  confusion  exists,  programmers  may  be  misled  by 
the  simplicity  of  the  discussion  on  TIME.  The  time  of  day  is  expressed  as  the  number  of 
seconds  (presumably  since  midnight  local  time).  This  is  contrary  to  many  embedded  systems 
which  operate  on  Mission  Time  or  Universal  Time  (Zulu),  although  iliis  is  still  possible  with 
the  current  definition  of  Ada.  Wliat  is  perhaps  missing  is  the  ability  to  update  the  system 
value  of  time.  This  problem  is  especially  acute  in  distributed  systems  since  they  frequently 
operate  from  independent  oscillators.  This  results  in  synchronization  being  required  at 
initialization  and  periodically  thereafter  due  to  differences  in  clock  rates. 

Application  software  within  tasks  frequently  time-tag  information  indicating  when  the  data 
was  sampled  from  the  external  device.  If  this  information  is  then  transferred  to  a  remote 
task  operating  on  a  separate  clock,  the  interpretation  of  the  time-tag  is  likely  to  be  faulty, 
resulting  in  error  or  even  system  failure.  Time  is  further  complicated  by  the  need  to 
synchronize,  because  it  will  result  in  some  of  the  clocks  being  forced  to  jump  forward  or 
even  backward  in  time.  This  noncontinuous  aspect  of  time  makes  synchronization  in 
distributed  systems  very  complex.  It  is  suggested  that  package  Calendar  be  expanded  to 
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support  applications  modifying  the  system  value  for  ^e.  Gear  semantics  must  be  specified, 
especially  with  respect  to  not  impacting  any  delays  currently  pending.  Ideally,  discontinuity 
in  time  should  be  allowed  to  "creep  back  on  schedule".  That  is,  an  epsilon  time  would  be 
provided  to  the  runtime  system,  which  would  gradually  advance/retard  the  clock  at  a 
specified  rate  until  the  epsilon  was  eliminated.  For  example,  if  the  clock  was  determined  to 
be  500  microseconds  behind  real  time,  an  epsilon  of  0.0005  would  be  specified  with  an  adjust 
rate  of  0.001.  This  would  imply  that  the  clock  would  be  accelerated  at  a  rate  of  0.1%  (1 
micro  second  per  millisecond)  until  it  was  on  "real"  time.  This  prevents  significant  errors 
during  computation  of  elapsed  time.  Another  approach  is  to  have  each  processor  maintain  a 
continuous  increasing  mission  clock  which  is  used  to  compute  elapsed  times  and  to  translate 
mission  time  to  time-of-day  whenever  necessary.  In  this  type  of  system,  each  processor 
keeps  an  adjustment  of  time  to  correct  differences  between  any  other  processor  with  which  it 
communicates.  Obviously  a  common  clock  stream  going  to  each  processor  is  a  preferable 
solution  to  any  of  the  above  if  the  system  architecture  supports  it. 

3)  A  Failed  Processor  Node  -  The  principle  designers  of  the  Ada  language  have  stated  that 
the  Ada  language  does  not  specify  what  happens  in  the  event  of  a  hardware  (CPU  or 
memory)  failure.  This  makes  tremendous  sense  from  the  point  of  view  that  no  set  of 
instructions  can  have  meaningful  semantics  if  the  underlying  hardware  is  unable  to  execute 
the  instructions  correctly.  However,  when  a  program  is  distributed  over  multiple  processors, 
and  one  fails,  the  integrity  of  the  other  processors  is  not  necessarily  compromised.  They 
could  conceivably  continue  to  function  correctly  and  it  might  be  appropriate  to  know  the 
semantics  of  any  interaction  with  tasks  or  data  on  that  failed  processor.  It  is  suggested  that 
the  semantics  of  such  a  failed  processor  node  be  identical  to  those  of  a  task  which  has  an 
unhandled  exception.  That  is,  the  task  will  go  to  completion.  Any  clients  in  a  rendezvous 
will  have  TASKING_ERROR  raised  at  the  point  of  call.  For  shared  data  on  that  node,  a 
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new  exception  should  be  defined,  such  as  ACCESS_ERROR,  which  will  be  raised  when  any 
access  to  storage  fails.  Note  that  this  is  different  than  STORAGE_ERROR  in  that  the 
latter  is  only  raised  when  available  storage  is  exceeded.  Recovery  from  the  two  types  of 
faults  is  likely  to  be  different.  The  ACCESS_ERROR  might  also  be  appropriate  for 
memory  errors  on  the  local  node  as  well.  Finally,  in  fault  tolerant  applications  where  a  node 
may  come  back  on-line  after  a  failure,  ACCESS_ERROR  might  be  a  more  general 
approach  to  reporting  an  error  during  rendezvous  than  TASKING_ERROR.  This  would 
allow  a  node  which  was  intermittently  accessible  due  to  communications  problems  to 
continue  to  operate  rather  than  require  otherwise  healthy  tasks  to  become  completed.  In 
these  situations  referencing  the  TERMINATED  and  'CALLABLE  attributes  while  the 
node  executing  the  designated  task  is  unreachable  would  also  raise  ACCESS_ERROR. 

4)  Package  System  -  prohibits  two  separate  representations  of  a  system  dependent  type 
within  the  same  program.  This  causes  diffiailiy  in  distributing  a  single  program  among 
heterogeneous  processors.  A  solution  might  be  to  create  a  function  "Processor"  which 
returns  a  static  enumeration  type  (ProcessorJType)  indicating  the  processor  the  program  is 
actually  executing  on.  Each  of  the  named  numbers  in  package  system  could  be  changed  to 
be  a  function  which  returns  a  static  value  and  takes  a  single  parameter  to  select  the 
processor.  The  default  parameter  for  the  function  would  of  course  be  the  "Processor" 
function.  Types  ADDRESS  and  NAME  could  similarly  be  referenced  by 
ADDRESS’CPU(Processor_Type)  which  returns  the  type  of  ADDRESS  on  the  specified 
processor.  Once  again  the  normal  types  for  ADDRESS  and  NAME  would  be  preserved  and 
would  refer  to  the  executing  processor.  [This  solution  may  need  tightening  up.] 

5)  Priority  preservation  by  the  network  is  an  issue  that  should  be  addressed  in  future 
language  revisions.  The  term  "available  processing  resources"  in  RM  9.8(3)  can  also  include 


-27- 


Demonstration  Project  Final  Report 


the  network,  since  it  may  be  managed  by  the  Ada  runtime.  The  RM  should  clarify  if  it  is 
acceptable  to  have  a  high  priority  task  blocked  waiting  for  low  priority  tasks  to  perform 
network  transfers.  The  preferred  approach  is  to  require  implementations  that  support 
priorities  to  also  have  the  priorities  apply  to  network  scheduling  as  well. 

72  Issues  Addressed  By  the  Demonstration  Project 

Essentially  every  paragraph  of  the  RM  Chapter  9  (Tasking)  has  an  impact  on  distributing 
Ada  programs  as  Ada  tasks.  Achieving  predictable  timing  in  a  distributed  Ada  application  is 
also  a  major  concern.  This  implies  the  ability  to  maintain  task  priorities  in  network 
transactions.  Most  commercially  available  network  hardware  does  not  support  preemption 
of  message  traffic  to  higher  priority  messages.  TTiis  results  in  a  high  priority  task  being 
blocked  while  lower  priority  tasks  transfer  data  (sometimes  referred  to  as  Priority 
Inversion),  Special  care  must  be  taken  to  avoid  this  effect  and  to  guarantee  response  time  to 
high  priority  tasks. 

The  issue  of  shared  memory  has  frequently  been  addressed  by  totally  restricting  its  use. 
Although  the  demonstration  project  did  not  need  distributed  shared  variables  for  the  initial 
prototype,  their  availability  would  give  greater  generality  to  what  can  reasonably  be 
distributed.  Some  analysis  was  done  however  to  determine  what  might  be  needed  to  support 
such  variables.  The  approach  that  would  be  used  to  implement  distributed  shared  variables 
would  be  to  assign  them  to  segments  which  could  be  mapped  as  "not  present"  by  the  memory 
management  system  in  the  processor.  The  segment  descriptor  tables  are  then  programmed 
to  recognize  segments  of  "Network  Data",  and  if  the  data  is  not  resident,  resi^lt  in  a  page 
fault.  This  page  fault  results  in  suspension  of  the  task  and  a  network  message  requesting  the 
data  being  multi  cast  to  all  processors  which  access  that  segment.  The  node  having  the  data 
marks  its  segment  as  being  not  resident  and  transmits  the  data  segment  to  the  requester. 
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Upon  receipt  of  the  data,  the  requester  marks  its-sepaent  as -resident  and  makes  ready  the 
suspended  task  for  execution  (possibly  preempting  a  lower  priority  task).  It  is  essentially  a 
complicated  version  of  virtual  memory,  utilizing  the  virtual  memory  support  provided  by  the 
80386  processor.  Several  types  of  Network  Data  are  envisioned:  Simple  Static  data  that 
does  not  migrate;  Migrate-able  Data  as  described  above;  and  Replicated  Data  that  is 
available  locally  in  read  form  on  all  processors,  but  can  be  written  only  by  a  single  master, 
resulting  in  a  broadcast  to  all  interested  nodes. 

7.3  Deferred  Issues 

The  following  issues  deserve  immediate  attention  but  are  well  beyond  the  scope  of  this 
project. 


Load  Management  -  (fynamic  task  migration  to  provide  the  desired  loading 

Fault  Tolerance  -  Detection,  Isolation,  Roll  Back  and  Recovery,  etc. 

Design  Issues  -  Paradigms  for  a  "good"  distributed  design 

Analysis  of  Distributed  Behavior  -  Predicting  overload  condititms,  deadlock,  etc. 

Limiting  the  Impact  of  Changes  in  Distributed  Systems  -  how  to  compensate  for  different 
performance  because  of  confi^ration. 

Incremental  Upgrades  While  On-Line  (Never-Stop)  -  dynamic  binding  of  Ada  name 
space.  Maintaining  system  state  in  the  presence  of  "new"  objects. 

D<;bugging  -  synchronous  halting  of  all  processors  and  system  clocks.  Providing 
"transparent”  network  debugging  support 

Heterogeneity  -  common  interchange  formats,  negotiation  of  desired  formats  between 
processors. 

Security  Barriers  -  Maintaining  multi-level  security  among  secure  processors.  Data 
labeling,  real-time  encryption,  trusted  network  software. 

Network  Interface  Standards  -  What  impact  does  "required"  compliance  with  OSI  (Open 
Systems  Interconnect),  MAP  (Manufacturing  Automation  Protocol),  or  GOSIP 
(Government  OSI  Profile)  have  on  real-time  systems?  Is  compliance  desirable? 

7.4  Architecture  Support 
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In  order  to  achieve  optimal  support  for  distributed  Ada  applications,  new  architectures  will 
be  necessary  that  closely  relate  to  the  Ada  semantics.  Although  this  topic  is  also  beyond  the 
scope  of  the  project,  several  ideas  regarding  ideal  architectures  have  come  to  light  while 
performing  work  on  the  project,  and  are  partially  documented  here. 

For  processors  that  can  be  connected  via  cables,  an  ACTIVE  STAR  network  may  provide 
good  solutions  to  many  of  the  distributed  Ada  problems.  Since  there  is  a  need  to  provide  a 
common  sense  of  time  among  distributed  ^tems,  the  star  hub  could  be  continuously 
transmitting  data  to  and  from  each  of  the  nodes.  This  data  stream  would  serve  several 
functions.  The  first  function  would  be  to  supply  a  common  and  constant  clock  stream  to 
each  of  the  nodes.  The  second  function  would  be  to  provide  constant  status  on  the  health  of 
each  node.  If  a  node  fails,  a  watch  dog  timeout  on  the  interface  card  would  trip  and  halt  the 
data  stream  to  the  hub.  This  would  result  in  a  "Failed"  status  at  the  hub.  Obviously  the  data 
streams  would  also  serve  to  transmit  data  to  and  from  the  hub  and  other  nodes.  Control 
information  embedded  in  the  stream  would  indicate  what  should  be  done  with  the  data. 

The  hub  design  is  absolutely  critical.  To  leave  out  functionality  would  result  in  significant 
performance  degradation.  As  a  minimum,  the  hub  should  support  the  following  capabilities: 

1)  It  should  be  able  to  be  replicated  to  provide  N-version  fault  tolerance. 

2)  It  should  preserve  the  priority  of  the  task  requesting  the  transfer  for  all  network 
transactions. 

3)  Network  Data  Store  (NDS)  should  be  provided  to  cache  shared  variables  and  to  bold 
the  necessary  data  to  resolve  inter-processor  tasking  states. 

4)  The  NDS  memoiv  should  be  high  speed  (under  35ns)  and  should  be  time  division 
multiplexed  among  all  nodes,  simulating  a  multi-port  memory. 

5)  Access  to  the  NDS  memory  should  include  primitives  for  indivisible  operations  such  as 
test  and  set,  and  atonuc  ADD  and  QUEUE  operations. 

6)  Security  provisions  should  be  included  to  electrically  prevent  data  labeled  as  classified 
from  being  transferred  to  a  node  of  lower  classification. 
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7)  Node  interfaces  to  the  network  should  appear  as  memory  in  the  processor  address 
space.  Task  control  blocks  for  tasks  which  have  remote  communications  should  be 
located  in  this  memory,  which  is  maintained  to  be  consistent  with  the  image  at  the  hub. 

8)  Node  interfaces  should  contain  a  64-bit  mission  clock  that  can  be  reset  simultaneously 
with  all  other  nodes,  stopped  simultaneously  with  all  other  nodes,  and  is  clocked 
simultaneously  with  all  other  nodes.  In  addition,  the  interface  card  would  have  a  32-bit 
40.233usec  clock  which  would  be  used  as  a  DURATION  mapped  delay  device.  Rather 
than  interrupting  the  CPU  at  a  regular  period,  the  timer  woufa  be  pro^ammed  with  the 
shortest  delay  currently  pending.  This  would  provide  very  accurate  delay  timeouts, 
without  incurring  overhead  when  delays  are  not  being  set  To  eliminate  the  software 
overhead  associated  with  determining  the  proper  value  for  the  timer,  custom  hardware 
could  be  supplied  that  would  accept  a  delay  value  and  a  task  ID.  The  hardware  would 
support  up  to  128  delays  directly  and  allow  software  to  resolve  any  delays  beyond  128  (at 
most  one  ^’true"  delay  need  be  set  by  any  task).  The  supplied  delay  would  be  added  to  the 
64-bit  clock  and  an  absolute  time  saved  in  a  register  nle  sorted  according  to  increasing 
time.  If  the  newly  requested  delay  is  earlier  than  the  earliest  delay  set,  its  time  would  be 
subtracted  from  the  ^bit  clock  and  the  resulting  value  placed  in  the  count  down  timer. 
As  times  expired,  the  earliest  time  would  always  be  placed  in  the  timer.  The  task  ED 
would  serve  to  notify  the  runtime  as  to  what  delay  timed  out  (along  with  an  interrupt  on  a 
promammable  level),  and  to  allow  for  cancelling  of  the  delay.  All  of  the  clock  circuitry 
could  easily  be  supported  within  a  current  technology  gate  array. 

9)  Built  in  Test  provisions  should  be  included  in  the  hub. 

10)  Debusing  support,  including  simultaneous  halting  of  all  nodes  (via  non-maskable 
interrupts  mom  interface  card)  should  be  an  option  for  hubs,  ‘'file  halt  would  also  serve 
to  disable  counting  in  all  node  clocks  so  that  perceived  real  time  is  uninterrupted. 
Obvious  features  such  as  data  logging  of  "meaningful"  data  should  be  conducted  at  the 
hub. 

11)  Provisions  to  provide  network  manager  control  from  one  or  more  privileged  nodes, 
fhis  might  include  getting  neh.vork  status,  forcing  a  clock  synchronization  with  a  new 
rhission  time,  broadcasting  data,  or  shutting  off  other  (wayward)  nodes. 

Such  hub  designs  are  believed  to  be  practical  witli  current  technology  for  reasonable  sized 

networks  (under  32  nodes,  however  each  node  could  be  a  cluster  of  processors  or  a  gateway 

to  a  hierarchy  of  other  nodes).  A  typical  medium  might  be  fiber  optics  for  long  haul 

applications  or  coax  cable  for  shorter  runs.  Data  rates  of  lOOMb/s  could  easily  be  achieved 

using  125MHz  modulation  with  5B/6B  codes.  The  effective  throughput  should  exceed 

12MB/sec  with  propagation  delay  times  typically  under  a  microsecond  in  the  absence  of 

contention. 
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8.  Timing  Analysis 

Timing  information  was  collected  for  several  purposes.  First,  to  insure  that  the  program  was 
operating  correctly  and  to  help  isolate  the  source  of  timing  problems.  Timing  information 
was  also  essential  to  evaluate  the  effect  of  optimizations.  Finally,  accurate  timing 
information  was  necessary  to  compare  the  relative  performance  between  the  single  and 
multiprocessor  versions  of  the  application. 

Timing  information  was  obtained  with  three  techniques.  The  first  technique  used  a 
preprocessor  to  insert  procedure  calls  to  a  time  stamping  routine.  These  were  inserted 
throughout  the  program  at  every  procedme  entry  and  exit  point,  as  well  as  task  rendezvous 
points.  In  addition,  the  runtime  was  modified  to  make  a  call  to  the  time  stamper  whenever  a 
context  switch  occurs.  This  made  it  possible  to  recognize  when  a  task  is  preempted,  and 
avoided  incorrect  charges  of  execution  time.  An  example  listing  resulting  fi-om  a  time  stamp 
execution  trace  appears  in  Appendix  G. 

The  time  stamp  mechanism  places  timing  information  as  well  as  a  unique  identifier  in  a 
circular  buffer  during  execution.  This  buffer  was  set  at  64K  bytes  and  used  8  bytes  per  time 
stamp.  It  "wraps"  every  8192  time  stamps,  overwriting  previous  time  stamps.  This  allowed  a 
trace  back  of  several  100ms  cycles  through  the  program  from  any  stopping  point.  It  was 
possible  to  edit  the  pre-processed  source  code  to  selectively  enable/disable  time  stamps 
which  extended  the  trace  back  up  to  several  minutes.  Additionally,  it  was  a  simple  matter  to 
disable  all  time  stamping  by  replacing  the  stamping  procedure  with  a  "return"  instruction. 
Since  the  time  stamp  procedure  requires  slightly  over  20  microseconds,  using  it  did  intrude 
on  program  execution.  Often  only  one  or  two  time  stamps  were  enabled  to  provide  accurate 
timings  without  significant  perturbation  of  the  program.  The  clock  used  had  a  resolution  of 
419  nanoseconds  and  is  software  extended  to  33  bits. 
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The  second  approach  to  timing  was  used  to  measure  aggregate  processor  utilization.  This 
technique  involved  use  of  custom  hardware  that  permitted  starting  and  stopping  one  or 
more  processors  simultaneously.  Essentially,  a  separate  communication  signal  was 
configured  that  could  invoke  a  non-maskable  interrupt  (NMI)  in  each  of  the  processors. 
ITiis  line  was  activated  by  a  dedicated  "timing"  processor  which  would  initially  signal  the 
processors  being  timed  to  start,  then  signal  again,  to  stop  the  processors.  Each  processor 
would  increment  a  coimter  within  a  tight  loop  during  their  "idle"  time.  The  value  in  the 
32-bit  counter  would  provide  a  measure  of  the  amount  of  time  spent  in  the  "idle"  loop.  As 
processor  saturation  occurred,  the  counter  would  not  increase  beyond  those  counts  that  had 
accumulated  during  initialization  (prior  to  reaching  a  steady-state  load).  After  close 
analysis,  it  was  determined  that  the  "idle"  loop  value  is  not  valuable  in  the  distributed  system, 
because  this  is  where  the  processor  waits  for  communication.  The  "idle"  time  therefore  gave 
i  false  impression  that  deadlines  could  be  met 

The  best  indication  of  meeting  deadlines  was  the  third  method  of  timing.  To  support 
periodic  processing,  each  task  computes  the  amoimt  of  time  necessary  to  delay  before  the 
beginning  of  the  next  period.  The  durations  computed  were  saved  in  a  buffer  using  an 
oach  similar  to  the  time  stamping  technique.  The  most  time  critical  task: 
"ROCKET.CONTROL"  was  monitored  in  this  way  to  record  how  close  it  came  to  tlie  next 
deadline.  If  the  duration  became  negative,  it  was  a  clear  indication  of  an  overrun  conditioiL 
That  is,  the  time  for  the  next  period  had  already  passed. 

Times  wete  collcaed  for  single  and  distributed  processor  configurations  and  are  reported  in 
Figure  2.  The  distributed  system  has  two  processors  connected  by  a  10  Megabit  per  second 
Ethernet  link.  The  results  clearly  indicate  that  the  remote  rendezvous  can  be  completed  in  a 
reasonable  time,  even  with  large  transfers  of  data  required  for  in  out  parameters;  and  that 
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there  is  a  substantial  performance  benefit  4o  distributing  the  program.  This  scenario  with 
the  distributed  architecture  allows  12  airborne  rockets  to  be  processed  before  deadlines  are 
missed,  while  the  single  processor  architecture  can  only  support  7  rockets  without  deadline 
overrun.  This  is  indicated  by  the  point  at  which  the  available  time  prior  to  the  next  period 
becomes  zero. 

Figure  3  shows  the  times  in  microseconds  required  to  perform  the  actual  intertask 
communication  using  the  distributed  runtime.  Note  that  the  overhead  roughly  approximates 
a  fixed  portion  of  17Sus  and  a  data  transfer  of  1  byte  every  4.03us. 
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MUraER  OF  ROCKETS 

0  5  10  15  20 

PROCESSOR 

Single  CPU  97ins  31im  *37m  -87iib  *102inB 

Distributed  95ais  61ms  27ms  •41ms  *69ms 

Figure  2.  Available  Time  prior  to  100ms  Deadline  for  Rocket.Control  (25  Targets) 


Ronntc  Rendezvous  Nferoseconds 

no  parair«ters  490 

1  out  parameter  202  bytes  990 

1  out  parameter  1002  bytes  4214 

For  the  1002  byte  rendezvous,  the  breakdown  is  as  follows; 

Hessage  setup/transmit  and  context  switch  110 

total  distributed  runtime  execution  including 

roteid-trip  message  transfer  and  second  context  switch  3737 

Out  parameter  copy  after  reception  (end  rendezvous)  367 


Figure  3.  Rendezvous  Timings 
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9.  Principle  Findings 

The  Ada  rendezvous  model  is  practical  (although  not  necessarily  ideal)  for  distributed 
communication.  Unconditional  rendezvous  with  small  parameter  lists  can  be  achieved  with 
off-the-shelf  communication  hardware  in  under  1  ms.  Although  this  is  significantly  higher 
than  the  lOOus  required  for  local  rendezvous,  it  is  still  acceptable  for  many  applications. 
More  complex  rendezvous  mechanisms  such  as  timed  entiy  calls  and  selective  waits  with 
delay  alternatives  impose  substantial  additional  overhead.  As  with  non-distributed 
applications,  the  synchronous  nature  of  the  Ada  rendezvous  imposes  additional  task 
constructs  in  order  to  "uncouple"  many  inter-task  communications. 

Although  Ada  compilers  now  are  near  to  being  "full"  implementations  of  the  language,  the 
most  complex  features  are  not  yet  reliable  enough  for  life-critical  applications.  Errors  in 
runtime  code  are  still  too  prevalent.  These  errors  are  extremely  difficult  to  detect  because 
they  only  occur  during  particular  coincidences  of  events.  A  general  example  is  the  execution 
of  some  particular  sequence  of  instructions  at  the  exact  moment  an  external  event  invokes  a 
context  switch.  This  sequence  utilizes  an  infirequently  referenced  flag  within  the  processor. 
If  the  state  of  the  task  is  not  fully  restored  after  the  context  switch,  the  particular  sequence 
may  fail  to  operate  correctly.  This  type  of  error  may  go  undetected  after  years  of  operation, 
only  to  result  in  total  system  failure  at  a  particular  instant. 

The  execution  rate  of  both  generated  code  and  the  runtime  code  is  considerably  better  than 
that  of  compilers  of  1986.  However,  checking  code  remains  verbose.  This  will  tempt 
real-time  application  developers  to  suppress  the  checks,  which  has  a  consequence  of  taking 
different  paths  through  the  code  generator.  Since  these  paths  may  not  have  been  tested  as 
thoroughly  as  the  primary  path  (generating  checks),  the  resulting  code  is  likely  to  be  less 
reliable. 
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The  speed  improvement  of  distributed  Ada  is  not  necessarily  scalable.  Although  the  parallel 
naiore  of  embedded  applications  make  them  ideal  for  multiple  processors,  the  individuals 
tasks  are  not  usually  balanced  in  processor  loading.  On  a  shared  memoiy  multiprocessor, 
scheduling  can  occur  on  a  "next  available  processor"  basis  but  this  is  usually  not  practical  on 
a  d’stributed  system  due  to  the  locality  of  data.  The  Vectorized  task"  is  a  partial  solution  to 
this  problem.  To  implement  the  guidance  operation  for  up  to  20  simultaneous  rocket 
trajectories,  an  array  of  tasks  was  used.  The  actual  size  of  the  array  was  controlled  by  a 
configuration  parameter.  Each  task  in  the  array  was  passed  a  list  of  rockets  to  guide.  If 
additional  processors  became  available,  the  size  of  the  array  could  be  increased  and  the 
tasks  could  be  distributed.  The  size  of  the  individual  WORK  lists  for  each  task  would 
decrease  correspondingly.  This  achieves  a  "near  scalable"  performance  increase  as 
processors  are  added. 

Tf.clmiques  for  achieving  distributed  Ada  via  pre-processing  the  source  code,  or 
post-processing  the  generated  code/runtime  are  acceptable  for  research,  but  unlikely  to  be 
so  for  any  production  environment.  What  is  required  is  an  integrated  compiler/linker/tester 
that  supports  distribution  of  programs.  A  flexible  compilation  system  would  support  several 
different  levels  of  distribution.  The  same  compiler  could  target  a  single  processor,  a 
shaied-meinory  multiprocessor,  or  a  physically  distributed  network  of  uodes,  consisting  of 
either  single  or  multiprocessors.  This  would  give  substantial  reconfiguration  capability  to 
system  designers.  Support  for  heterogeneous  processors  would  additionally  allow 
customization  of  the  configuration  to  provide  the  best  match  of  processing  resources  for 
application  requirements. 

Some  aspects  of  the  Ada  language  definition  are  silent  about  what  should  happen  in  a 
distributed  system.  For  example,  if  a  node  fails,  should  future  rendezvous  to  a  task  in  that 
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node  get  TASKING_ERROR  or  simply  deadlock?  What  about  a  rendezvous  already  in 
progress  with  a  failed  node?  What  if  the  node  fails,  but  then  returns  to  service?  These  are 
all  likely  scenarios  in  typical  distributed  systems.  A  clear  statement  about  what  can  be 
expected  in  these  situations  (or  possibly  control  over  what  happens  via  pragmas)  is  necessary 
in  future  language  revisions.  Another  area  is  the  interpretation  of  the  timed  entry  call.  If 
the  delay  duration  is  >  0.0  and  yet  the  delay  expires  prior  to  a  message  being  sent  to  the 
remote  task,  should  the  rendezvous  be  terminated  even  if  the  accepting  task  is  ready  for  an 
"immediate"  rendezvous?  Refer  back  to  section  7.1  "Language  Issues"  for  more  detail  and 
other  areas  of  concern. 

A  software  manager  should  not  use  Ada  on  a  serious  real-time  project  without  source  code 
to  the  runtime  system.  This  is  not  for  the  purposes  of  modifying  it,  but  rather  to  understand 
the  detailed  execution  when  necessary.  This  information  is  not  available  in  even  the  best 
vendor  documentation  (which  is  sometimes  incorrect  anyway)  but  can  only  be  verified  by 
examining  the  source  of  the  runtime. 

10.  Summary 

This  report  discusses  the  advantages  and  issues  associated  with  using  the  Ada  tasking  model 
for  real-time  distributed  systems.  A  case  is  made  for  reducing  the  overhead  of  the  remote 
rendezvous  (and  shared  variable  access)  so  that  its  use  becomes  practical.  Some  issues 
regarding  the  clarity  of  the  Ada  Standard  are  presented  and  possible  interpretations  are 
suggested.  Several  open  issues  are  listed  as  areas  that  require  further  study.  These  issues 
such  as  fault  tolerance,  security,  and  dynamic  re-configuration  are  extremely  complex  taken 
one  at  a  time,  and  become  even  more  complex  in  any  combination. 
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A  real-time  demonstration  project  is  described  and  was  used  to  evaluate  the  effectiveness  of 
the  distributed  Ada  tasking  approach.  It  also  served  to  shed  light  on  other  implementation 
issues  with  Ada  not  associated  with  distribution.  The  demonstration  software  should  prove 
helpful  to  other  projects  wanting  to  evaluate  real-time  performance,  or  to  evaluate  the 
capabilities  of  compilation  systems  with  respect  to  real-time  embedded  applications. 
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12.  Appendix  A  •  Specification  for  the  Border  Defense  System 

Ihe  following  document  contains  a  description  of  a  hypothetical  battle  management  system 
used  to  defend  a  border.  The  purpose  of  this  description  is  to  act  as  a  low  level  ^stem 
specification  for  the  development  of  software  to  implement  such  a  system.  This  software 
^^l  be  used  to  assess  the  feasibility  of  using  distributed  Ada  tasks  on  multiple  processors 
using  a  "source  transformation"  approach.  Tne  assessment  will  be  geared  towards  real-time 
systems,  and  therefore  the  hypothetical  system  contains  aspects  that  will  fail  totally  if  not 
processed  in  the  allocated  time  period. 

In  support  of  the  real-time  analysis  of  the  ^tera,  a  combined  Target  Generator  and  Rocket 
Simulator  will  be  developed  to  provide  inputs  to,  and  process  outputs  from  the  Border 
Defense  System  system.  Althoum  the  code  in  the  simulator  will  also  be  written  in  Ada,  its 
development  will  not  be  analyzed  as  part  of  the  study. 

12.1  Overview 

The  Border  Defense  System  (BDS)  is  designed  to  protect  a  defined  border  against  invasion. 
It  accepts  target  position  information  from  a  surveillance  system,  and  generates  a  real-time 
color  graphics  display  for  an  operator  to  observe  battlefield  activity.  THie  operator  selects 
targets  by  positioning  a  target  reticle  with  a  pointing  interface  and  pressing  an  "fire"  button. 
These  selected  targets  are  then  engaged  by  the  BDS,  which  will  launch  a  rocket  and  provide 
real-time  guidmce  data  for  the  rocket  to  the  point  of  intercept.  The  graphics  display  is 
updated  to  indicate  progress  of  the  rocket  flights  (as  reported  by  encrypted  rocket  messages) 
in  real-time.  Post  attack  assessment  information  is  provided  to  the  operator  as  well  as  the 
niunber  of  active  targets  and  rockets. 

12.2  Requirements 

12.2.1  Target  Display 

The  target  display  shall  support  a  minimum  of  350  x  600  picture  elements  (pixels)  of 
resolution,  with  a  minimum  of  16  simultaneous  colors  selected  from  among  a  minimum  of 
256  colors.  The  display  shall  be  mapped  to  a  battle  area  of  4km  x  4km.  The  BDS  shall 
support  displayinga  minimum  of  100  simultaneous  targets.  Target  Report  messages  will  be 
provided  to  the  BDS  from  the  Sensor  Subsystem  at  a  rate  of  lOHz.  Each  report  message  will 
contain  iim  to  100  target  reports  as  specified  in  the  Sensor  Interface  Desi^  Document 
(IDD).  These  taiget  reports  contain  target  information  including  the  target  identification, 
classification,  and  position.  Targets  shall  be  displ^ed  at  the  position  on  the  display 
corresponding  to  their  reported  position  on  the  battlefield.  Target  symbols  shall  be  current 
within  250ms.  Target  symbols  shall  consist  of  a  minimum  of  8  contiguous  pixels  and  shall  be 
color  coded  to  indicate  target  classification  and  engagement  status.  Multiple  targets  that 
nvip  to  the  same  screen  position  may  appear  as  a  sin^e  target  or  overlap. 

12.2.2  Operator  Commands 

The  BDS  shall  support  input  from  an  operator  in  the  form  of  messages  from  a  hand 
operated  pointing  device,  containing  a  minimum  of  three  control  buttons.  The  current 
position  of  the  pointing  device  shall  be  superimposed  on  the  display  in  the  form  of  a 
targeting  reticle  and  shml  be  current  within  50ms.  The  targeting  reticle  shall  consist  of  the 
comers  of  a  square  box  (minimum  side  of  10  pixels)  with  cross  hairs  in  the  center.  While  in 
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"manual"  mode,  if  the  operator  presses  the  "fire"  button,  the  BDS  shall  command  the  Rocket 
Control  System  to  launch  a  rocket,  and  will  track  the  target  closest  to  the  pointing  position 
for  interception  by  that  rocket.  Targets  that  are  engaged  shall  change  color  so  as  to  appear 
brighter.  If  more  than  20  rockets  are  active,  the  "fir^  button  be  ignored.  Pressing  of  the 
"reset"  button  shall  result  in  battlefield  cumulative  statistics  being  cleared.  The  third  button 
shall  toggle  the  BDS  between  manual  and  automatic  modes.  In  automatic  modes,  the  "fire" 
button  shall  be  ignored,  and  target  eneagement  shall  be  selected  by  the  BDS.  The  target 
closest  to  the  protected  border  shall  suways  be  selected.  By  default,  the  MANUAL  mode 
shall  be  selected  upon  ^tem  initialization.  Pressing  of  any  single  button  shall  result  in  the 
desired  action  within  250ms.  When  more  than  one  button  is  pushed  simultaneously,  they 
shall  be  processed  in  the  order  of  MODE,  FIRE,  and  RESET. 

1223  Rocket  Control 

12.23.1  Encryption  (Phase  H) 

All  rocket  data  link  messages  shall  be  encrypted  according  to  the  Data  Encryption  St^dard 
(DK).  Encryption/Decryption  shall  be  done  on  all  rocket  reports  and  rocket  guidance 
update  data  within  the  messages.  Other  fields  shall  be  transmitted  as  plain  text.  Key 
management  shall  be  in  accordance  with  "Key  Control  for  the  Border  Defense  System" 
document  (Appendix  J). 

12.2.3.2  Rocket  Reports 

Rocket  report  lists  will  contain  up  to  20  rocket  reports  that  have  been  collected  by  the 
Rocket  Control  System  and  transferred  to  the  BDS  via  the  Rocket  Data  Link.  The  format 
of  the  received  report  lists  is  specified  in  the  Rocket  Data  Link  Interface  Design  Document. 
Rocket  report  lists  will  arrive  at  the  BDS  at  a  lOHz  rate  to  provide  new  position  data  for 
each  active  (in  flight)  target. 

12.2.3.3  Rocket  Guidance 

Rocket  guidance  lists  shall  be  generated  at  a  lOHz  rate  and  will  contain  new  attitude  control 
data  for  each  rocket  in  flight  TTiese  lists  shall  be  transmitted  via  the  rocket  data  link  to  the 
Rocket  Control  System  for  up-link  to  the  rockets.  Each  rocket  will  be  assigned  a  unique 
(with  respect  to  all  in-flight  rockets)  identification  number  by  the  BDS.  Upon  recognition  of 
a  new  rocket  ID,  the  Rocket  Control  System  will  launch  an  addition^  rocket  (up  to  20  active 
rockets).  Failure  to  provide  rocket  guidance  data  for  each  rocket  within  100ms  will  result  in 
the  rocket  performing  an  automatic  self  destruct  (due  to  concerns  about  countermeasures). 

12.2.4  Battle  Status 

Battlefield  conditions  and  statistics  shall  be  continuously  displayed.  At  a  minimum,  the 
numbers  of  active  targets  and  rockets,  total  numbers  of  targets  destroyed  and  rockets 
expended  since  the  last  reset  shall  be  ported  on  the  display.  The  display  will  also  clearly 
indicate  the  mode  of  operation  (AUTOMATIC  or  MANUAL).  Battle  status  shall  be 
current  within  1  second. 

12.3  Performance  Requirements 
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The  BDS  shall  provide  100%  hit  rate  while  operating  in  the  absence  of  effective 
countermeasures  and  with  the  conditions  specified  m  the  Parameter  Data  Base  (Appendix 
B). 

12.4  Quality  Assurance  Requirements 

The  BDS  Software  shall  be  developed  in  the  Ada  language  (ANSI/MIL  STD  1815A-1983) 
in  accordance  with  Defense  System  Software  Development  standards  (MIL-STD-2167A). 
No  assembly  language  is  permitted.  Ada  "CODE"  statements  may  be  used,  but  are  limited 
to  50  code  statements.  A  Contracting  Agency  approved  coding  style  guide  (Appendix  F) 
shall  be  adopted  and  adhered  to  in  production  of  all  deliverable  code. 
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13.  Appendix  B  •  Parameter  Data  Base 


packagt  POB  (t 

This  psekase  specifies  the  Pamseter  Data  Base  for  the  BOS 
Siflulatar.  It  provides  a  conplate  structure  for  siiulator 
••{  peraMters  Mhieh  can  ba  aodified  on-line. 

grid.size  :  constant  :■  4000;  — |  4kai  square 

type  CRID.TYPE  is  range  0..grid_size; 

type  DEGREES_TYPE  is  digits  6  range  0.0  ..  360.0;  — |  in  circle 

type  C0UNT_TYPE  is  range  0.. 32767;  --|  used  for  mst  counters 

type  INTERVAL^TYPE  is  new  DURATION  range  0.001  ..  1000.0; 

**(  allowable  intervals 

type  RATE.TYPE  is  digits  5; 

•*1  used  for  all  rate  calculations 


TARGET  INFORMATION 


subtype  MAX_TARGETS.RANGE  is  CQUNT.TYPE  range  1..1000; 

-|  RANGE  FOR  MAXIMUM  NUMBER  OF  TARGETS 

subtype  CREATE.RANGE  is  INTERVAL.rrPE  range  0.1  ..  10.0; 

—  I  INTERVAL  BETWEEN  NEW  TARGETS 

subtype  VELOCITY_TYPE  is  RATE_TYPE  range  0.001  ..  1000.0; 

-•|  Allowable  velocities  in  weter s/sec. 


subtype  VELOCITY_CHAN6E_RANGE  is  INTERVAL_TTPG  range  0.1  ..  60.0; 

—  I  INTERVAL  BETWEEN  CHANGES  IN  TARGET  VELOCITY 


subtype  TAR0£T_TURN_RATE_RAN0E  is  RATEJYPE  range  0.01  ..  20.0; 

-•|  Valid  target  turn  rates 

type  TARGET_MAX_TURN_ANGLE_RANGE_TYPE  is  digits  4  range  0.1  ..  360.0; 

-•|  degrees 

type  TARGET.KILL.RANGE.TYPE  is  digits  3  range  1.0  ..  100.0;  — |  maters 
subtype  TARGET_TURN_INTERVAL_TYPE  is  RATE.TYPE  range  1.0  ..  1000.0; 

—  I  seconds  between  turns 


type  TARGET_CLASS_TYP€  is 
(  UNKNOWN. 
TSO.TANK, 

BMP.2); 


•-(  Supported  Target  Classifications 
-•|  Unidentified  target 
•-|  Pact  Main  Battle  Tank 
-I  Mobile  SAM 

•-|  Armored  Personnel  Carrier 
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TARGET  PARAMETER  TYPE  is  rKOrd 


«AXIMUM_VELOClTY 
AVERACg^VELOCITY 
VELOCl TY_CHAMGE_I  MTERVAL 
MAXIMUM_Tl)RM_RATE 
NAX^TURN.ANGLE 
TURN.INTERVAL 
VULNERABILITY_RA0IUS 
end  record; 


VELOCITY_TYPE;  ”|  travel  In  K-eeters/hour 
VELOCl TY_TYPE;  --|  travel  In  K*iMters/hour 
VELOCl TY.CHANGE.RANGE;  "I  In  aeconds 
rARGET_TURN_RATE_RANGE;  "j  degrees  per  second 
TARGET_MAX_TURN_ANGLE_RANGE;  —I  deflrees  per  turn 
TARGET_TURN_INTERVAL_RANGE;  “|  In  seconds 
TARCET_KILL_RAMGE;  Bieters 


MAXIMUM_TARGETS  ;  MAX_TARCETS_RAMGE  :■  100; 

"I  This  value  specifies  the  absolute  isaxisMs  nunber  of 

*-|  targets  allowed  to  be  actively  reported  in  any  one  report. 


TARGET_CREATE_1NTERVAL  :  CREATE.RANGE  :>  create_range' last; 


Indicates 

the  rate  at  which 

targets  shall  be 

.  --|  generated  to  achieve 

the  MAX.TARGETS  value. 

TARGET_PARAMS  is  arrey<TARGET_CLASS_TYPE) 

of  TARGET_PARAMETER_TYPE 

(  UNKNOWN  » 

(  MAX1MUM_VEL0CITY 

s> 

100.0 

• 

AVERAGE_VEL0C1TY 

•> 

30.0 

VELOC 1  TY_CHANCE  .  I NTERVAL 

s> 

15.0 

# 

MAXlMl«JURM_RArE 

-*> 

20.0 

« 

MAX_TURN^AN0LE 

s> 

200.0 

T'JRN^I  NTERVAL 

m> 

2.0 

$ 

VULNERABILirV^RAOIUS 

M> 

5 

TSO^TANK  »> 

<  MAX1MUM_VEL0CITY 

a> 

90.0 

# 

AVERAGE_VELOCITY 

«> 

50.0 

9 

VELOC 1 TY_CHANGE_I MTERVAL 

«> 

10.0 

9 

MAXIMUM_TURN_RATE 

■> 

30.0 

9 

MAX_TURM_AMGLE 

s> 

100.0 

9 

TURM_I NTERVAL 

«> 

5.0 

9 

VULNERAB I L I TY_RAD 1 US 

), 

SA_9  ■>  --  Gaskin  Surfact 

m> 

6 

g  to  Air  Missile  Launcher 

(  HAXIMUM_VELOCITY 

«> 

96.0 

9 

AVERAGE.VELOCITY 

m> 

67.0 

9 

VELOC I TY_CHAM0E_I NTERVAL 

m> 

30.0 

9 

MAXIMUM_TURN_RATE 

m> 

10.0 

9 

MAX_TURM_AMGLE 

m> 

90.0 

9 

TURN_I  NTERVAL 

m> 

15.0 

9 

VULNERABIL1TY_RA01US 

). 

BMP_2  ■>  --  Armored  Troop 
(  MAXIMUM_VELOCITY 

m> 

12 

Carrier 

■> 

59.0 

9 

AVERAGE.VELOCITY 

m> 

42.0 

9 

VELOCl TT_CHANGE_I NTERVAL 

m> 

25.0 

9 

MAXIMUM_TURN_RATE 

m> 

5.0 

9 
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MAX.TURN.ANGLE 

S> 

80.0  '  , 

TMfN.INTERVAL 

m> 

25.0  , 

VULNERABILITY.RADIUS 

m> 

8 

-•  end  of  array 

TARG6T_aiEATE_RATlO  ft  trrty<TARGET_CLASS_TYPE)  of  COWIT^TYPE  :■ 
(UNKNOUN  ■>  10,  T80_TANK  »  50,  SA_9  »  20,  BMP_2  »  20); 
nuabers  of  each  class  created  per  100  targets 

TARG€T_R6P0RT_H(TERVAL  :  IRTERVAL.TYPE  :«  0.1;  — |  seconds  per  report 


ROCKET  IMFORMATIOM 


subtype  MAX  ROCKETS  RANGE  is  COUNT  TYPE  range  1..100; 

alloHable  range  for  nurtter  of  rockets 

NAYifPJM.ROCKETS  :  NAX_ROCKETS,RANGE  :>  10;  —|  mnber  of  active  rockets 

type  MASS_TYPE  is  digits  5  range  10.0  ..  100.0;  — |  rocket  aass 

type  THRUST.TYPE  is  digits  6;  **|  force  in  Neutons 

type  BURN_RATE_TYPE  is  digits  5  range  0.001  ..  10.0;  **|  kg/second 

type  RESISTANCE.TYPE  is  digits  S  range  0.001  ..  100.0;  Nsec/« 

type  0RIFT_VELOCITY_TYPE  is  digits  5  range  0.001  ..  0.5;  — |  neters/sec. 

subtype  R0CXET_TURN_ACCEL_TYPE  is  neu  RATEJYPE  range  0,01  ..  1000.0; 

-*|  acceleration  in  degrees  per  second  squared 

type  ROCKET_PARAMETER_TYPE  is  record 

MASS.TYPE  :■  25.0;  -|  kg  (no  fuel) 

MASS.TYPE  :■  13.0;  -|  kg 
THRUST_TYPE  :■  750;  — |  Newtons 
8URN_RATE_TYPE  :■  1.0;  — |  kg/second 
BURN_RATE_TYPE  :■  0.2;  --j  kg/socend/degree 
RESISTANCE_TYPE  :■  0.4;  — |  Newton-seconds/neter 
RESISTANCE_TYPE  ;■  75.0;  —j  Newton-seconds/Meter 
0RIFT,VEL0CITY_TYPE  ;■  0.2;  —1  neters/second 
ROCKET_TURN_ACCEL_TYPE  :>  300.0,— |  degrecs/sec 
GRID.TYPE  :■  grid_size/2.0; 

GRIO.TYPE  :■  0.0; 

GRID.TYPE  ;»  0.0; 

OEGREES.TYPE  :■  90.0; 

DEGREES.TYPE  :■  90.0; 

end  record; 


MASS 

FUEL 

THRUST 

BURN.RATE 

TURN.BURN.RATE 

FORUARO.ORAG 

SIDE.DRAG 

DRIFT 

TURN.RATE 

LAUNCH.X 

LAUNCH.Y 

LAUNCN.Z 

LAUNCH.AZIMUTH 

LAUNCH  ELEVATION 
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ROCKET  ;  ROCKET_PARAMETER_TYPE;  —1  hold  all  rocktt  paraa»teP8 
ROCKET_REPORT_mTERVAL  ;  IMTERVAL.TYPE  !■  0.1;— j  Intarval  batwaan  raporta 
end  POB;  -*|  Paraaiatar  Data  Base 
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14.  Appendix  C  •  Sensor  Interface  Design  Document 


Border  Defense  System  (BDS) 

SENSOR  Interface  E^ign  Document 
Release  X.0 

14.1  Purpose 

This  document  describes  the  interface  between  the  BDS  Sensor  Subsystem  (SS)  and  the 
Main  Control  Unit  (MCU).  All  messages  are  described  as  well  as  the  general  protocol. 

14.2  References 

The  ETHERNET,  A  Local  Area  Network  Data  Link  Layer  and  Physical  Link  Layer 
Specifications",  Version  2.0  1982,  Xerox  Corporation,  Stamford  Connecticut. 

143  Requirements 

14.3.1  Protocol 

Transmissions  will  be  in  accordance  with  the  standard  Ethernet  Specifications.  This  applies 
to  the  Carrier  Sense,  Multiple  Access  with  Collision  Detection  CSMA/CD  mechanism  as 
well  as  the  bina^  exponential  back  off  technique.  Standard  Destination  and  Source  Address 
Fields,  Length,  Type,  and  Frame  Check  Sequence  (FCS)  fields  shall  be  imposed  to  facilitate 
packet  transport. 

14.3.2  Error  Recovery 

Error  recovery  will  be  as  follows:  Errors  shall  be  detected  and  logged.  Data  within  an 
incorrect  packet  shall  be  discarded  and  the  previous  state  of  me  system  shall  be 
extrapolated  forward  in  time.  Multiple  errors  may  cause  performance  of  the  system  to 
degrade,  including  but  not  limited  to  loss  of  target  representation  and/or  accura^  loss  in 
rocket  guidance. 

1433  Network  Address  Assignments 

Nttwork  Address  Assignments: 

Mein  Control  Unit  ■  02*60*AC-00*00-01  (hexadecimsl) 

Sensor  Subsystem  ■  82*60-4C*00*00*02  (hexsdecimel) 

Rocket  DL  Subsystem  •  82*60*4C*00'00*03  (Kexadecimsl) 

(Note  To  Facilitate  Laboratory  Simulation  Testing  Sensor  Subsystem  and  Rocket  Data  Link 
message  addresses  are  "Multi-Cast"  addresses  and  can  both  be  received  by  a  simulator  if  it  is 
configured  to  receive  multi  cast  addresses.) 

143.4  Word  Format 

Byte  order  for  data  fields  after  the  standard  Ethernet  header  shall  be  transmitted  Least 
significant  byte  first. 
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Specifically,  fields  after  "MSG_LENGTH"  shall  be  in  a  format  that  is  directly  compatible 
with  the  80X86  family  byte  ordering.  For  example: 

Muiber_of_Targ*ts  - 

Byte  Offset  62:  Least  Significant  Byte 
Byte  Offset  63:  Host  Significant  Byta 

143.5  Message  Summary 

Message  Name  Direction  Size  (Bytes)  Rate 


Target_Llst  SS  to  NCU  64.. 862  10Hz  Nosilnal 

Tlme.Sync^INIT  NCU  to  SS  64  0.01  Hz 


14.3.6  Message  Descriptions 

_  4 

14.3.6.1  Target_List  Message 

Direction:  Sensor  Subsystem  =  >  Main  Control  Unit 
Size:  64..862  Bytes 

Rate:  10  Hz  +  /-10% 

Description:  The  Target  list  provides  updated  information  on  each  target  in  the  Area  of  Interest 
(AOI).  A  single  time-tagTs  associated  with  all  reports  in  the  list  Up  to  100  target  reports  may  be 
contained  in  the  list. 
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TARGET  LIST  MESSAGE 


FIELD 

|SIZE|START  1 

RANGE 

1  UNITS 

1  {offset  1 

1 

Destination  Addr 

^  1 

1 

0 

1 

• 

1  48*bit  Net  address 
1 

Source  Addr 

1 

6  1 

6 

1 

• 

1 

1  46*bit  Net  eddrest 
1 

MSG.Type 

1 

2  1 

1 

12 

1 

Fixed  at  5 

1 

1  Integer  10 

1 

NSC_Length 

1 

2  1 

1 

14 

1 

64. .862 

1 

1  Integer  Count 

1 

Tisia_Tag 

1 

4  1 

1 

16 

1 

0..2**32 

1 

1  20.11  usee 

1 

Spare 

1 

42  1 

1 

20 

1 

- 

1 

1 

Nuiber_of_Targcts 

1 

2  1 

62 

1 

0..100 

1 

\\\\\\\\\\\\\\\\\\V\\\\\\\\\\\\\\\\\\V\\\\\\\V\\V\V\\\\\\\U 
The  follOMing  fields  are  provided  in  accordance  with  the  nunber 
of  tarflets  specified  above. 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 


Target^ReportOI  | 
Target_I001  j 

2 

1 

1 

64 

0.. 32767 

1  Integer  ID 

Target_X_POS01  | 

2 

1 

66 

0.0..3000.0 

1  0.125  laeter 

Taroet_Y_POS01  j 

2 

1 

68 

0.0.. 5000.0 

1  0.125  meter 

Terget.ClaseOI  | 

1 

2 

1 

70 

0..3 

1  TargetjClass 

1 

Target_Report02  | 
Target_I002  | 

2 

1 

1 

1 

72 

0. .32767 

1  Integer  ID 

Taroet_X_POS02  | 

2 

1 

74 

0.0. .3000.0 

1  0.125  meter 

Target_r_POS02  | 

2 

1 

76 

0.0.. 5000.0 

1  0.125  meter 

Target_Class02  | 

2 

1 

78 

0..3 

1  Target.Class 

a  a 

1 

a  a  a 

a  a  a 

1  a  a  a 

e  a 

1 

a  a  a 

a  a  a 

1  a  a  a 

a  a 

1 

a  a  a 

a.a 

1  a  a  a 

Target_Report_N  | 
Target_I0_M  | 

2 

1 

1 

8N>56 

0.. 32767 

1  Integer  ID 

Target_X_POS_M  | 

2 

1 

8N4S8 

0.0. .3000.0 

1  0.125  meter 

Target_Y^POS_M  \ 

2 

1 

8IF»60 

0.0. .5000.0 

1  0.125  meter 

Target_Class_N  | 

2 

1 

8IH62 

0..3 

1  TargetjClass 

*  Refer  to  table  in  section  3.1 


14  J.6.2  Destination  Address 
Refer  to  Ethernet  Specification. 
143.63  Source  Address 
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Refer  to  Ethernet  Specification. 

143.6.4  Message  Type 

Refer  to  Ethernet  Specification. 

143.6.5  Message  Length 
Refer  to  Ethernet  Specification. 

143.6.6  Time  Tag 

This  32  bit  value  provides  a  time-of-day  in  20.11  microsecond  ticks.  It  will  be  roU  over  at 
midnight  and  reset  to  zero  at  that  time.  This  value  represents  the  time  at  which  the  sensor 
scan  was  taken  which  resulted  in  the  following  target  list. 

14.3.6.7  Spare 

This  field  is  reserved  for  future  use. 

14.3.6.8  Number  of  Targets 

Tins  16  bit  value  contains  the  number  of  targets  REPORTED  in  this  message.  It  ranges 
from  0  to  100.  For  each  target  there  is  a  Target  Report. 

14  3.6.9  Target  Report  (N) 


A  Target 
16  bit 
16  bit 

16  bit 

16  bit 


Report  consists  of: 

Target  ID  *  a  wiique  nuaber  identifying  a  target. 

X  position  •  fixed  point  ('SMALL  of  0.125)  indicating 

X  offset  relative  to  Left  most  Grid  border, 
r  position  •  fixed  point  ('SMALL  of  0.125)  indicating 
T  offset  relative  to  Nearest  Grid  border. 
Target  Class  -  Indicating  one  of  four  target 
classifications  as  follows: 


0  -  Unknown 

1  •  TOO  Battle  Tank 

2  -  SA-9  "GASKIN" 

3  •  BMP*2  Infantry  Coiabat  Vehicle 

Target  reports  exist  for  each  target  being  tracked  (up  to  100).  If  two  consecutive  target 
reports  arrive  with  a  previously  tracked  target  missing,  it  is  presumed  destroyed  or  masked. 
In  either  case,  the  display  will  no  longer  indicate  existence  of  the  target,  and  rockets 
on-route  will  be  vectored  to  the  last  known  position  extrapolated  accortung  to  their  last 
known  rate. 


143.7  Time  Synchronize/Initialize 
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Direction:  Main  Control  Unit  «  >  Sensor  Subs^tem 
Size:  64  Bytes 

Rate:  0.01  Hz 

Descriotion:  The  Time  Synchronize/Initialize  message  commands  the  Sensor  Subsystem  to  set 
its  clock  to  the  provided  value  and  to  begin  (or  continue)  issuing  target  lists.  All  time  tags 
received  after  transmission  of  this  message  shall  be  time-tagged  with  respect  to  this  new  time. 


143.7.1  Destination  Address 
Refer  to  Ethernet  Specification. 

14.3.7.2  Source  Address 
Refer  to  Ethernet  Specification. 

14.3.73  Message  Type 

Refer  to  Ethernet  Specification. 

14.3.7.4  Message  Length 
Refer  to  Ethernet  Specification. 

143.73  Spare 

This  field  is  reserved  for  future  use. 

143.7.6  Time  Tag 

This  32  bit  value  contains  the  current  time  in  20.11  microsecond  increments.  Zero  (0)  refers 
to  midnight  Universal  Time  (UT). 
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15.  Appendix  D  •  Rocket  Data  Link  Interface  Desi^  Document 


Border  Defense  System  (BDS) 
ROCKET  Data  Link  Interface  Design  Document 
Release  1.0 


15.1  Purpose 

This  document  describes  the  interface  between  the  BDS  Rocket  Data  Link  (RDL)  and  the 
Main  Control  Unit  (MCU).  All  messages  are  described  as  well  as  the  general  protocol. 

15.2  References 

The  ETHERNET,  A  Local  Area  Network  Data  Link  Layer  and  Physical  Link  Layer 
Specifications",  Version  2.0  1982,  Xerox  Corporation,  Stamford  Connecticut. 

15.3  Requirements 

153.1  Protocol  Transmissions 

Protocol  Transmissions  will  be  in  accordance  with  the  standard  Ethernet  Specifications. 

This  applies  to  the  Carrier  Sense,  Multiple  Access  with  Collision  Detection  CSMA/CD 

mechamsm  as  well  as  the  binary  exponential  back  off  technique.  Standard  Destination  and 

Source  Address  Fields,  Length,  Type,  and  Frame  Check  Sequence  (FCS)  fields  shall  be 

imposed  to  facilitate  packet  transport 
« 

15.3.2  Error  Recovery 

Error  recovery  will  be  as  follows:  Errors  shall  be  detected  and  logged.  Data  within  an 
incorrect  packet  shall  be  discarded  and  the  previous  state  of  the  system  shall  be 
extrapolated  forward  in  time,  y  Multiple  errors  may  cause  performance  of  the  system  to 
degrade,  including  but  not  limited  to  loss  of  target  representation  and/or  accura^  loss  in 
rocket  guidance. 

153.3  Network  Address  Assignments 


Network  Address  Assignments: 

Hein  Control  Unit  ■  02'60-iC*00*00-01  (hexadecimal) 

Sensor  Subsystem  *  82*60-4C-00-00-02  (hexadecimal) 

Rocket  OL  Subsystem  •  82*60*4C-00*00*03  (hexadecimal) 

(Note  To  Facilitate  Laboratory  Simulation  Testing,  Sensor  Subsystem  and  Rocket  DL 
Subsystem  message  addresses  are  "Multi-Cast"  addresses  and  can  both  be  received  by  a 
simulator  if  it  is  configured  to  receive  multi  cast  addresses.) 

153.4  Word  Format 

Byte  order  for  data  fields  after  the  standard  Ethernet  header  shall  be  transmitted  Least 
significant  byte  first 


-53- 


Demonstration  Project  Final  Report 


Specificallv,  fields  after  "MSG_LENGTH" 'shall  be  in  a  format  that  is  directly  compatible 
vwth  the  80X86  family  byte  ordering.  For  example: 


Nu>btr_of_Rock«ts  ■ 

Byte  Offset  62:  Least  Significant  Byte 
Byte  Offset  63:  Most  Significant  Byte 


153  J  Message  Summaiy 


Message  Nane 


Direction 


Size  (Bytes)  Bate 


Rocket_Report_List  ROL  to  MCU 
Rocket_Guidance_List  MCU  to  ROL 
Time.SyncJNIT  MCU  to  ROL 


64..  302  10Hz  Nosiinal 

64..  862  10Hz  Noainal 

64  0.01  Hz 


153.6  Message  Descriptions 

15.3.6.1  Rocket_Report_List 

Direction:  Rocket  Data  Link  =  >  Main  Control  Unit 
Size:  64.302  Bytes 
Rate:  10  Hz  +  /-10% 

Description:  The  Rocket  Report  List  provides  upclated  information  on  each 
rocket  in  flight  A  separafe  time-tag  is  associated  with  each  report  in  the 
list  Up  to  20  rocket  reports  may  be  contained  in  the  list  The  Rocket  Data 
Link  subsystem  receives  messages  from  the  rockets  asynchronously  over  the  100ms 
period,  and  combines  all  of  the  reports  into  a  sin^e  message  for  the  Main 
Control  Unit. 

NOTE:  The  Target  Report  Fields  in  the  following  message  are  encrypted. 

ROCKET  REPORT  LIST  MESSACX 


. FIELD 

|SIZE| 
1  1 

START  1 
OFFSET  1 

RANGE 

1  UNITS 

Oeatinetlon  Addr  |  6  | 

0  1 

I 

1  48-bIt  Net  addreaa 

Source  Addr 

1  1 
1  6 

1 

1 

6  1 

1 

* 

1  48-bIt  Net  address 

MSG_Type 

1 

1  2 

1 

1 

12  1 

1 

Fixed  at  2 

1  Integer  ID 

MSG.Length 

1 

1  2 

1 

1 

1^  1 

1 

64. .862 

1  Integer  Count 

Spare 

1 

1  ^ 

1 

1 

16  1 

1 

- 

1 

1 

Huter  of_Rockets|  2  | 

1 

1 

^  1 

1 

0..20 

1  Integer  Cowt 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\N\\VN\\\\\V\\\\\ 

The  folloMing  fields  arc  provided  In  accordance  with  the  rtmtotr 
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*  Refer  to  table  In  section  3.1 

15.3.6.2  Destination  Address 
Refer  to  Ethernet  Specification, 

15.3.6.3  Source  Address 


Refer  to  Ethernet  Specification. 

153.6.4  Message  Type 

Refer  to  Ethernet  Specification. 

153.6.5  Message  Length 
Refer  to  Ethernet  Specification. 

153.6.6  Spare 

This  field  is  reserved  for  future  use. 


15.3.6.7  Number  of  Rockets 
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This  16  bit  value  contains  the  number  of  fockets  REPORTED  in  this  message.  It  ranges 
from  0  to  20.  For  each  rocket  there  is  a  Rocket  Report. 

153.6.8  Rocket  Report  (N) 


A  Rocket  Report  conelstt  of: 


32  bit  TiM  Teg 
16  bit  Rocket  10 
16  bit  X  position 

16  bit  Y  position 

16  bit  Z  position 


-  TiM  the  Rocket  reported  its  position. 

•  a  uiique  nunber  identifying  e  Rocket. 

•  fixed  point  ('SMALL  of  0.125)  indicsting 

X  offset  reletive  to  Left  Mst  Grid  border. 

-  fixed  point  ('SMALL  of  0.125)  indiceting 
T  offset  reletive  to  Neerest  Grid  border. 

•  fixed  point  ('SMALL  of  0.125)  indiceting 
2  offset  reletive  to  Grouid  Level. 


Rocket  reports  exist  for  each  rocket  in  flight  (up  to  20).  If  two  consecutive  rocket  reports 
arrive  with  a  previously  reported  rocket  missing  it  is  presumed  to  have  terminated  flight.  In 
this  case  the  jdisplay  wm  no  longer  indicate  enstence  of  the  rocket,  and  no  rocket  guidance 
messages  will  be  generated  for  that  rocket. 

153.7  Rocket_Guidance_List 

Direction:  Main  Control  Unit  *  >  Rocket  Data  Link 
Size:  64.302  Bytes 
Rate:  10Hz+/-10% 

Description:  The  Rocket  Guidance^List  provides  updated  direction  information 
for  each  rocket  in  flight.  The  new  direction  is  to  be  applied  immediately  by 
the  receiving  rocket  Up  to  20  rocket  guidance  messages  may  be  contained  in 
the  list.  The  Rocket  Data  Link  subsystem  will  simultaneously  transmit  ail 
messages  to  the  rockets. 

NOTE:  The  Direction  Fields  in  the  following  message  are  encrypted. 

RIXXET  GUIDANCE  LIST  MESSAGE 


FIELD 

(SIZE( 
1  1 

START  1 
OFFSET  1 

RANGE 

1  UNITS 

Desttnatfon  Addr  |  6  | 

0  1 

• 

1  48*bit  Nat  addraas 

Sourct  Addr 

1  1 
1  6 

1 

6  1 

1 

• 

1  46*b1t  Nat  addrao* 

MSG.Typa 

1 

1  2 

1 

12  1 

1 

Flxad  at  3 

1  Intagar  ID 

NSG_L«ngth 

1 

1  2 

1 

1 

14  I 

1 

64. .862 

1  Intagar  Cowt 

Spar* 

1 

1 

1  1 

1 

16  I 

1 

- 

1 

Nuiter  of  RockattI  2  | 

II 

62  1 

1 

0..20 

1  Intagar  Count 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\V\\\\\\\V\\\\\\\\\\\\\\\\\\\ 
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The  following  fie 


ds  are  provided  in  accordance  with  the  nudxr 


of  rocketa  apecified  above. 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 


Rocket^ReportOI 


Rocket_I001 

2 

1 

68 

0.. 32767 

Rocket.AzimOl 

2 

1 

70 

-32768.. 32767 

Rocket_Elev01 

2 

1 

72 

-32768. .32767 

Rocket_Report02 

Rocket_I002 

2 

1 

1 

74 

0.. 32767 

Rock«t_Azirn02 

2 

1 

76 

-32768.. 32767 

Rocket_Elev02 

2 

1 

1 

68 

-32768. .32767 

... 

a 

1 

... 

a  a  • 

. . . 

•• 

1 

... 

a  a  a 

•••  . 

•• 

1 

... 

a  a  a 

Rocket_Report_M 

Rocket^lO_M 

2 

1 

1 

6N>62 

0.. 32767 

Rocket^Azim.N 

2 

1 

6N>64 

-32768.. 32767 

Rocket  Jlav_M 

2 

1 

6N^ 

-32768.. 32767 

Integer  10 
BAM 
BAM 


Integer  10 
BAM 
BAM 


Integer  10 
BAH 
BAM 


*  :Iefer  to  table  in  section  3.1 


l:i  .,3 .7. 1  Destination  Address 
Refer  to  Ethernet  Specification. 
153.12  Source  Address 
Refer  to  Ethernet  Specification. 
153.7.3  Message  Type 
Refer  to  Ethernet  Spedfication. 
15.3.7.4  Message  Length 
Refer  to  Ethernet  Spedfication. 
153.7.5  Spare 

This  field  is  reserved  for  future  use. 


153.7.6  Number  of  Rockets 

This  16  bit  value  contains  the  number  of  rockets  GUIDED  in  this  message.  It  ranges  from  0 
to  20.  For  each  rocket  there  is  a  Rocket  Direction. 

15.3.7.7  Rocket  Direction  (N) 
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A  Rocket  Direction  consists  of: 

16  bit  Rocket  10  •  s  urtique  nutber  identifying  s  Rocket. 

16  bit  Aziauth  •  Angle  in  Rinsry  Angle  Neasurenents  with 

respect  to  the  T  axis.  LS8  ■  1/32768  degrees. 

Positive  direction  is  rotstion  clockwise 
about  the  Z  axis. 

16  bit  Elevation  •  Angle  in  binary  Angle  NeasuresMnts  with 

respect  to  the  Y  axis.  LS8  ■  1/32768  degrees. 

Positive  direction  is  rotation  up,  about 
the  X  axis. 

153.8  Time  Synchronize/Initialize 

Direaion:  Main  Control  Unit  =  >  Rocket  Data  link 
Size:  64  Bytes 

Rate:  0.01  Hz 

Description:  The  Time  Synchronize/Initialize  message  commands  the  Rocket  Data 
Link  to  broadcast  the  time  to  all  ground  based  rocket  launchers.  These  units 
will  set  their  clocks  to  the  provided  value.  Just  prior  to  launch,  rockets 
will  be  given  this  time,  and  therefore  time-tags  within  rocket  messages  will  be 
with  respect  to  the  new  time. 

TINE  SYNCHRONIZE/INITIALIZE  MESSAGE 


FIELD 

Destination  Addr 
Source  Addr 
MSG_Type 
MSG_Length 
Tine_Tag 


SIZE 


START 

OFFSET 


0 

6 

12 

U 

16 


RANGE 


Fixed  at  0 
64 

0..2*^2 


UNITS 

48-bit  Net  address 
48-bit  Net  address 
Integer  ID 
Integer  Count 
20.11  usee 


15.3.8.1  Destination  Address 
Refer  to  Ethernet  Specification. 

153.8.2  Source  Address 
Refer  to  Ethernet  Specification. 

153.8.3  Message  Type 

Refer  to  Ethernet  Specification. 

153.8.4  Message  Length 
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Refer  to  Ethernet  Specification. 

153.8.5  Spare 

This  field  is  reserved  for  future  use. 

15.3.8.6  Time  Tag 

This  32  bit  value  contains  the  current  time  in  20.11  microsecond  increments.  Zero  (0)  refers 
to  midnight  Universal  Time  (UT). 
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16.  Appendix  E  •  Specification  for  the  BDS'Test  Simulator 

16.1  Scope 

This  document,  in  conjunction  with  the  Rocket  Data  Link  Interface  Design  Document 
(IDD),  Sensor  Data  Link  IDD,  and  the  Parameter  Data  Base  (PDB),  specifies  the 
requirements  for  the  BDS  Simulator  systenL 

16.2  Applicable  Documents 

Reference  Manual  for  the  Ada  Programaino  Language  (ANSI/MIL-STD-181SA*1983) 


Defense  System  Software  Oevelopownt  (MIL*ST0-2167*198S) 


Rocket  Data  Link  Interface  Design  Docunent 


Sensor  Data  Link  Interface  Design  Docunent 


Parameter  Data  Base  for  the  BOS  Simulator 

16.3  Requirements 

The  Simulator  for  the  BDS  system  provides  simulated  inputs  and  outputs  for  the  BDS 
Sensor  and  Rocket  Interface  Units.  It  serves  to  allow  complete  testing  of  the  BDS  in  the 
laboratory. 

16J.1  Sensor  Simulation 

16J3.1.1  Target  Data  in  Parameter  Data  Base 

The  BDS  Simulator  shall  generate  simulated  sensor  data  in  accordance  with  the  values 
specified  in  the  Parameter  Data  Base.  ITiese  parameters  shall  be  interpreted  as  follows: 

163.1.1.1  MAXIMUM_TARGETS 

This  value  specifies  the  absolute  maximum  number  of  targets  allowed  to  be  actively  reported 
in  any  one  report. 

16.3.1.1.2  TARGET_CREATE_INTERVAL 

Indicates  the  interval  at  which  targets  shall  be  generated  to  achieve  the  MAX_TARGETS 
value. 

16.3.1.13  TARGET  CHARACTERISTICS 
Provides  the  characteristics  of  each  target  class. 

163.1.13.1  MAXIMUM_VELOCrrY 
Maximum  vehicle  velocity. 


Demonstration  Project  Final  Report 


163.1.132  AVERAGE_VELOCrrY 
Average  vehicle  velocity. 

163.1.133  \^UDCrrY_CHANGE__INTERVAL 
Interval  between  target  velocity  changes. 

16.3.1.1.3.4  MAXIMUM jrURN_RATE  (angular  velocity) 

The  maximum  rate  at  which  a  vehicle  can  turn. 

163.1.133  TURN_INTERVAL 

The  interval  at  which  a  new  direction  is  taken. 

163.1.13.6  MAX  TURN  ANGLE 
Maximum  turn  angle  for  any  single  turn. 

16.3.1.13.7  VU1J^RABIIJTY_RADIUS 

The  radius  about  the  vehicle  center  that  will  result  in  destruction  if  a  rocket  strikes. 

163. t  5.4  TARGET^REPOKT_INTERVAL 
Frequency  of  new  target  report  messages. 

16.3.1.2  Target  Creation 

Target  creation  shall  occur  at  the  TARGET  CREATE_INTERVAL  until  the 
MAaIMUM_TAKGETS  count  has  been  achieved.  Tliereafter,  targets  will  be  created  at 
this  rate  to  niaintain  destroyed  taigets.  Targets  shall  be  created  in  the  ratio  of  target  classes 
specified  in  the  PDB  TARGET_CLASS_RATIO  values.  Target  starting  positions  shall  be 
initialized  according  to  random  coordinates  between  zero(O)  and  the 
MAXIMUM_START_X  and  MAXIMUM_START_Y  values  in  the  PDB.  Targets  are 
considered  "active”  as  soon  as  they  are  created. 

163.1.3  Target  Motion 

Target  motion  will  be  simulated  using  random  numbers  to  provide  actual  motions  within  the 
maximums  specified  in  the  PDB.  "Random”  values  shall  have  a  normal  distribution  within 
03  times  the  standard  deviation  and  a  scaled  average  of  0.5  +/-10%  for  samples  sizes  with  n 
>  100.  The  random  sequence  period  shall  be  greater  than  2**16.  Random  numbers  will  be 
uniform  in  the  range  [0,1). 

Target  motion  shall  always  be  forward  (^creasing  "Y"  grid  offset  values).  Turns  made  by 
targets  shall  be  made  at  the  TURN_INtERVAL  specified  in  the  PDB  within  -0/+ 200ms. 
Vehicles  will  chaMe  direction  at  a  rate  that  is  a  random  factor  of  the  MAX_TURN_RATE 
specified  in  the  PDB.  For  the  purposes  of  this  simulation,  the  vehicle  is  assumed  to  achieve 
the  maximum  turn  rate  instantaneously.  The  desired  turn  angle  shall  be  determined  as  a 
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random  factor  of  the  MAX  TURN_ANGLE,  restricted  by  maintaining  forward  motion. 
The  change  in  direction  shalTcontinue  until  the  desired  turn  angle  is  reached,  or  until  a  new 
turn  is  initiated. 

Target  travel  shall  be  determined  by  a  random  factor  of  the  AVERAGE  VELOCITY  but 
not  exceeding  the  MAXIMUM  VELOCITY  values  specified  in  the  PDBT  Target  velocity 
shall  be  recomputed  at  the  VELOCITY  CHANGE  INTERVAL  specified  in  the  PDB  with 
-0/+ 200ms. 

All  target  motion  computations  shall  be  done  with  sufficient  accuracy  so  that  the  resultant 
positions/times  are  correct  within  1  meter. 

163.1.4  Target  Reports 

Target  reports  shall  be  generated  at  the  TARGET  REPORT_INTERVAL  specified  in  the 
PDB  within  +/-  2ms.  Target  reports  shall  be  in  the  format  Ipecified  in  the  Sensor  Data 
Link  IDD.  Target  reports  shall  contain  an  entry  for  each  of  the  active  targets.  Targets  shall 
be  considered  active  from  the  time  they  are  created  until  they  are  destroyed  or  reach  a 
coordinate  of  range  that  is  zero  (Y=0). 

163.2  Rocket  Simulation 

16.3.2.1  Rocket  Guidance 

Rocket  Guidance  Lists  will  be  received  from  the  BDS  main  control  unit  in  accordance  with 
the  Rocket  Data  Link  IDD.  All  rocket  motions  shall  be  simulated  with  respect  to  the  time 
at  which  the  Guidance  Lists  are  received.  If  new  rocket  ID’s  appear  in  the  list,  the  simulator 
shall  initiate  a  launch  for  each  of  the  new  ID’s.  Initial  rocket  coordinates  and  vectors  for 
launch  shall  be  taken  from  tlie  PDB  parameters  LAUNCH  X,  LAUNCH  Y,  LAUNCH  7^ 
LAUNCH__AZIMUTH,  and  LAUNCH_ELEVATION.  -  -  - 

163.2.2  Rocket  Report  Lists 

Rocket  Rraort  Lists  shall  be  generated  at  the  rate  specified  in  the  PDB  value 
ROCKET  REPORT_RATE  -0/+3ms.  Report  Lists  shall  contain  the  current  simulated 
position  of  each  of  the  active  rockets.  Rockets  shall  be  considered  active  after  receipt  of  a 
new  rocket  ID  in  a  rocket  guidance  list  until  the  rocket  reaches  a  zero  (0)  relative  altitude 
(Z  coordinate  »  0)  after  fli^t  of  at  least  2  seconds. 

163.2.3  Rocket  Termination 

Rocket  Termination  shall  cause  a  simulated  detonation  which  will  destroy  any  simulated 
targets  that  are  within  their  respective  vulnerable  radius. 

163.2.4  Rocket  Data  in  Parameter  Data  Base 

The  BDS  Simulator  shall  generate  simulated  rocket  data  in  accordance  with  the  values 
specified  in  the  Parameter  Data  Base.  These  parameters  shall  be  interpreted  as  follows: 

1633.4.1  MAXIMUM_ROCKETS 
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Contains  the  maximum  number  of  active  rockets.  Anjr  new  rocket  ID’s  that  arrive  in 
guidance  messages  which  would  result  in  exceeding  tlm  value  shall  result  in  an  error 
message  on  the  operator  display.  Such  requests  for  laimch  will  be  ignored. 

16.3.2.4.2  R0CKET_CHARACTER1STICS 
163.2.42.1  ROCKET_MASS 

Take  off  weight  of  the  rocket  (in  kg). 

16.32.4.2.2  ROCKET_FUEL 
Amount  of  rocket  propellant  (in  kg). 

163.2.423  ROCKET^THRUST 
Force  of  rocket  engine  (in  Newtons). 

163.2.4.2.4  BURN_RATE 

Rate  at  which  propellant  is  consumed  (in  kg)  for  forward  thrust. 

16.3.2.4.2.5  TURN_BURN_RATE 

Rate  at  which  additional  propellant  is  consumed  for  each  degree  of  rotation/second -squared 
effe‘’i.ed. 

16.3.2.4.2.6  FORWARD  DRAG 

Reactive  force  of  air  resistance  to  forward  velocity. 

16.3.2.42.7  SIDE_DRAG 

Reactive  force  of  air  resistance  to  sideslip  velocity.  Note  that  the  rocket  is  nearly 
symmetrical  about  its  center  line  axis,  and  therefore  side  drag  is  independent  of  which  side  is 
traveling  into  the  air  resistance. 

16  3.2.4.2.8  DRIFT 

Rocket  motion  due  to  wind  (m/sec).  Tliis  is  a  maximum  value  to  be  modified  by  a  random 
factor. 

16.3.2.4.2.9  ROCKET_TURN_RATE 

It  is  the  maximum  acceleration  the  rocket  can  achieve.  For  simplification,  the  vectored 
thrust  for  tiuming  can  be  considered  to  have  no  effect  on  the  forward  thrust  (that  is, 
additional  fuel  is  used  for  turning.)  This  fuel  is  burned  at  the  rate  of  the 
TURN_BURN_RATE  value. 

163.2.42.10  Launch  Data 
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LAUNCH  X  LAUNCH  Y,  LAUNCH  Z,  LAUNCH  AZIMUTH,  and 
LAUNCHnELEVATIOlT  provide  the  attitude  and  position  of  the  rocket  at  launch. 

1632.43  ROCKET_REPORT__RATC 

The  rate  at  which  rocket  position  report  lists  are  transmitted  to  the  6DS  main  control  unit. 
16323  Rocket  Motion 

Rocket  motion  shall  be  computed  at  least  as  frequently  as  required  by  the 
ROCKET_REPORT_INTERVAL.  Rocket  motion  shall  compensate  for  drag,  angular 
acceleration  rates,  gravity,  changes  in  rocket  mass  and  other  drift  due  to  wind.  When  the 
propellant  has  been  expended  and  the  rocket  is  still  in  flight,  it  shall  continue  to  travel  at  the 
heading  it  was  at  when  the  fuel  ran  out. 

All  rocket  motion  computations  shall  be  done  with  sufficient  accuracy  so  that  the  resultant 
positions/times  are  correct  within  1  meter. 

16.33  Parameter  Data  Base  On-Line  Update 

Data  Base  changes  shall  occur  in  a  consistent  fashion.  Specifically,  all  parameters  for  a 
single  rocket  or  sensor  list  operation  will  be  static.  This  implies  that  a  synchronization  of  the 
data  base  update  with  access  from  either  the  rocket  simulation  or  sensor  simulation  must  be 
performed. 

Values  in  the  PDB  will  be  changed  in  accordance  to  the  Operator  Interface  Requirements 
section  of  this  document 

16.3.4  Scenario  Generation/Playback 

The  BDS  Simulator  shall  have  the  capability  to  process  a  previously  generated  target 
movement  scenario  rather  than  using  random  motions.  An  orf-lme  tool  shml  be  provided  to 
assist  in  producing  scenarios,  and  to  allow  selection  of  a  particular  scenario  for  execution. 
The  scenario  shall  support  a  sufficient  number  of  targets  and  target  positions  so  as  to 
efficiently  utilize  up  to  256KB  of  simulator  memory. 

1633  Time  Synchronization 

163.5.1  Sensor  Subsystem 

The  Sensor  Subsystem  shall  accept  a  Time  Synchronize/Initialize  command  and  set  its 
internal  time  reference  accordingly.  TTiis  intemm  reference  shall  be  used  to  supply  time  tags 
on  messages  and  perform  all  time  related  computations. 

1633.2  Rocket  Data  Link 

The  Rocket  Data  Link  shall  accept  a  Time  Synchronize/Initialize  command  and  set  its 
internal  time  reference  accordingly.  This  internal  reference  shall  be  used  to  supply  time  tags 
on  messages  and  perform  all  time  related  computations. 
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It  is  anticipated  that  time  synchronization  will  be  required  within  lOOus  to  achieve  the 
specified  accuracies. 

163.6  Operator  Interface 

16.3.6.1  Operator  Display 

The  Operator  Display  shall  indicate  current  status  of  the  simulation  as  well  as  issue 
command  prompts  and  echo  operator  inputs.  The  displayed  data  shall  be  updated  at 
intervals  not  to  exceed  1  second.  Simulation  data  shall  consist  of  a  least  the  foUowmg  items: 


0  of  targets  activa/total 

*  of  rockets  aetive/total 

#  of  destroyed  targets 

*  of  rocket  aisses 

#  of  targets  reaching  coordinate  "YsO" 


LatMt  Error  Statue 

The  format  of  the  displayed  data  shall  be  proposed  by  the  contractor  and  will  require 
approval  of  the  contracting  agency. 

16.3.6.2  Operator  inputs 

Opepitor  inputs  shall  be  menu  oriented.  All  operator  inputs  shall  be  checked  for  validity, 
and  errors  will  allow  the  operator  to  reenter  the  data.  At  aiiy  time,  the  operator  shall  be 
able  to  enter  an  <  ESCAPE  >  (ASCII  27)  characier  to  return  to  the  top  level  menu. 

16.3.63  Parameter  Data  Base  Variables 

All  Parameter  Data  Base  variables  shall  be  accessible  to  display  and/or  modify  via  the 
operator  interface.  Allowable  ranges  for  variables  shall  be  displayed  in  the  data  entry 
prompts. 

16.3.7  BuUtInTest 

Built  In  Test  shall  be  performed  with  sufficient  firequencjr  to  detect  a  stable  hardware  fault 
in  the  Encryption  unit  within  1  second.  Such  faults  will  be  indicated  on  the  Operator 
Display  and  mvoke  an  automatic  degraded  mode  of  operation  using  software  enc^tion. 
This  degraded  mode  will  reduce  the  number  of  active  targets  to  a  maximum  of  10,  and  the 
number  of  active  rockets  to  1.  All  rockets  in  flight  in  excess  of  the  degraded  mode  maximum 
during  initiation  of  degraded  mode  will  continue  to  be  tracked.  However  no  guidance 
messages  will  be  processed  and  no  target  reports  generated  for  these  rockets. 

16.4  Quality  Assurance  Requirements 

16.4.1  Software  Development 

All  software  shall  be  developed  in  accordance  with  MIL*STD-2167.  Designs  shall  be 
reviewed  prior  to  proceeding  with  implementation.  Code  walk  throughs  shall  be  conduaed 
on  all  software  to  insure  proper  design,  style,  and  performance  objectives. 
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16.4J2  Test  Procedures 

Test  procedures  will  be  written  so  that  testing  can  be  conducted  in  an  automatic  fashion  to 
the  greatest  extent  possible.  Testing  shall  m  conducted  on  all  requirements  to  insure 
compliance  with  this  specification  and  any  lower  level  specifications  (SDDD  in  particular). 

16.43  Error  Budgets 

Error  budgets  for  all  timing  and  calculations  shall  be  documented  to  indicate  where 
allowable  errors  may  occur. 

16.4.4  Programming  Language 

The  only  pro^anuning  language  shall  be  Ada.  No  code  statements  shall  be  used  without 
prior  approval  of  the  contracting  agency.  No  assembly  statements  shall  be  used. 

16.43  Implementation  Dependent  Features 

Implementation  dependent  features  shall  be  limited  to  the  greatest  extent  possible. 
Consideration  for  transporting  the  software  to  a  new  RunTime  Environment  will  oe  made 
when  evaluating  different  techniques  in  implementation. 
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17.  Appendix  F  •  Ada  Style  Guide 


Version  2.1 


17.1  Introduction 

This  document  was  developed  to  provide  guidance  in  the  consistent  generation  of  Ada 
software.  If  used  properly,  the  effect  should  be  to  minimize  the  likelihood  of  coding  errors, 
improve  the  readabihty  of  the  code,  simplify  the  work  involved  in  making  minor  alterations 
to  the  code,  and  facilitate  documentation  devdopment.  Transportabilify  and  reusability  are 
addressed  through  careful  use  of  language  features. 

17.2  Identifiers 

Tlie  following  statements  describe  the  standards  that  will  apply  to  identifiers: 

1.  All  Reserved  word  identifiers  will  be  in  lower  case. 

2.  All  type  and  subtype  identifiers  will  be  in  upper  case,  and  will  have  the  suffix  "_TYPE". 

3.  AU  variable  identifiers  will  be  in  upper  case. 

4.  All  enumeration  literals  will  be  in  upper  case. 

5.  Aii  access  variables  will  have  the  suffix  "_^PTR". 

6.  All  constant  identifiers  will  be  in  lower  case. 

7.  All  other  identifiers  will  have  their  first  character  in  upper  case  with  their  remaining 
characters  in  lower  case.  For  names  containing  embedded  underscores,  the  first  character 
after  each  underscore  should  be  in  upper  case.  Exceptions  will  be  made  for  common 
acronyms  such  as  "10",  they  will  appear  m  upper  case:  "Text_IO". 

173  Identification,  Alignment,  and  Spacing 

The  following  conventions  should  be  used: 

1.  Standard  indentation  will  be  two  (2)  spaces. 


Example: 

if  ROCKET_IN_FLIGHT  then  Rocket  ia  already  airborne 
Enable  (TRACKER); 

else 

Calibrate  (SENSOR); 
end  if; 


2.  Multiple  conditions  in  an  "if..."  clause  should  be  grouped  together,  placed  on  appropriate 
lines,  and  aligned  so  as  to  enhance  clarity. 
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Exaople: 

If  (OPERATOR.COMMAND  3  LAUNCH)  or 

(TAKCET.SELECTEO  and  AUTOMAT  I  C.MOE)  than 
Launch^Rockat; 
and  ff; 


3.  Each  statement  will  be  on  a  different  line. 

4.  The  reserved  words  "begin",  "exception",  and  "end",  when  used  in  a  subprogram 
specification,  should  be  aligned.  The  code  within  these  reserved  words  should  be  mdented 
two  spaces. 

5.  Loop  initiators  and  loop  terminators  should  be  aligned.  The  body  of  the  loop  should  be 
indented  two  spaces: 


Example: 

loop 

RESULT  :>  Attempt_Aligniwnt; 
exit  alien  RESULT  >  GOOD; 
end  loop; 


6.  A  blank  space  will  precede  and  follow  each  operator  except  for  exponentiation  or 
negation. 

17.4  Comments 

1.  A  comment  header  will  be  placed  at  the  beginning  of  each  subprogram,  package,  task,  or 
generic  unit.  The  PDL  templates  should  be  adequate  which  contain: 


■*|  Effects:  Dascrlbas  overall  effect  of  this  code  section 
Modifies  States  ahat  fllobal  objects  are  modified  directly 
"I  Requires  Indicates  ahat  initialization  is  required  prior  to  invocation 
--|  Raisas  Declares  idiat  exceptions  are  potentially  explicitly  raised  and 
propagated  froai  the  subprogram 

SOOO  Lists  ahat  Software  Detailed  Design  Oocuaent  requirements 
are  fulfilled  by  this  code  section. 

-•|  Engineer  Provides  the  principle  designer/coder. 

*•(  Classification  (for  classified  projects  only)  Indicates  security 

requirements  for  this  code  section.  Appropriate  responses  are: 
TOP.SECRET,  SECRET,  CONFIDENTIAL,  UNCUSSIFIED.SEMSITIVE, 
or  UNCLASSIFIED 

The  "SENSITIVE*  designation  applies  to  information  that  is 
ITAR  Restricted,  Export  Controlled,  Proprietary,  or  otherwise 
available  on  a  *nead*te*kneu"  only  basis. 


Other  standard  keywords  may  be  added  to  the  template  on  a  project  basis. 
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2.  An  Else  statement  should  always  have  an  embedded  comment  associated  with  it 


Exanple: 

<f  ERROR  th«n 
Cancel (LAUNCH); 

else  --no  error 

Ffre  (ROCKET); 
end  if; 

3.  A  comment  line  will  be  used  to  describe  a  relatively  long  set  of  related  statements 
requiring  special  attention. 

4.  A  blank  line  should  proceed  and  follow  each  comment  line,  except  for  those  comment 
lines  that  make  up  header  blocks. 

_  / 

5.  The  use  of  embedded  comments  is  encouraged.  However,  care  should  be  taken  not  to 
obscure  the  code. 

6.  The  beginning  of  each  rendezvous  statement  (possibly  compound)  will  be  clearly 
identified  with  a  comment  consisting  of  a  full  line  of  dollar  signs. 

17.5  PDL  Compatibility 

The  ]  '  )L  will  be  e)^anded  to  produce  the  operational  code.  Therefore,  there  must  be  a  way 
to  separate  the  "him  level"  constructs  from  the  low  level  code.  A  mechanism  for  this  is 
supported  by  the  PuL  marker,  which  consists  of 1  ["  at  the  end  of  an  Ada  statement.  Ada 
code  statements  which  should  be  included  in  the  PDL  listing  should  have  this  marker.  Note 
that  this  marker  should  only  appear  in  non-declarative  regions. 

17.6  Restrictions 

1.  The  use  of  exception  handlers  to  process  errors  from  predefined  exceptions  that  are 
known  to  be  possible  and  can  reasonably  expected  (i.e.  hardware  faults)  is  prohibited.  They 
should  only  be  used  to  respond  to  une^ected  errors  that  are  the  result  of  software  design 
problems  or  exceptions  that  are  explicitly  "raised".  In  this  way,  it  may  be  possible  to 
eliminate  all  runtime  checking  by  using  the  suppress  pragma  if  the  implementation  is 
sufficiently  trustworthy. 

2.  "USE"  clauses,  in  general,  are  allowed  only  for  Language  defined  packages.  (Those  that 
appear  in  the  Reference  Manual).  In  cases  where  a  large  number  of  package-defined 
operators  are  used,  then  the  "use"  clause  may  be  utilized  ONLY  for  convenience  of 
reference  to  operators.  Other  objects  in  packages  must  be  referenced  via  the  fully  expanded 
name,  or  by  usine  a  "renames"  statement  or  a  subtype  declaration.  Objects  referenced  from 
ancestor  units  win  use  fuUy  expanded  names  as  well. 

3.  Use  of  Generics  must  be  explicitly  approved  by  the  Software  Manager.  This  is  primarily 
to  coordinate  their  use,  rather  than  to  discourage  using  generics. 
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4.  Records  with  Default  Discriminants  are  prohibited  unless  explicitly  approved  by  the 
Software  Manager.  A  statement  indicating  the  j>erfonnance  and  size  impact  of  these 
structures  should  be  included  in  the  approval  request. 

5.  Subprograms  are  limited  to  no  more  than  100  lines  of  code  (semicolons).  Compilation 
units  should  be  limited  to  less  than  500  lines  of  code. 

6.  Overloading  of  names  (including  operators)  is  limited  to  cases  where  the  functionality  is 
very  similar,  otherwise  names  will  not  be  overloaded. 

7.  Package  Specifications  and  Bodies  will  be  separately  compiled.  Specifications  will  have 
the  suffix  "_S"  on  file  names;  bodies,  including  subunits  will  have  the  suffix  "^B". 

8.  References  to  global  data  should  be  restricted  to  the  extent  possible.  That  is,  whenever  it 
is  feasible  subprograms  should  only  operate  on  parameters.  For  efficiency  reasons,  global 
data  may  be  accessed  when  necessary.  This  must  ALWAYS  be  documented  in  the 
subprogram  header.  ^  cases  where  the  same  set  of  parameters  are  closely  related  it  may  be 
appropriate  to  combine  them  into  a  record  type,  and  pass  the  entire  record  as  a  single 
parameter.  Be  cautioned  to  the  fact  that  overhead  associated  with  subprogram  invocation 
can  be  substantial. 

9.  The  use  of  tasks  must  be  coordinated.  Therefore  task  declarations  are  prohibited  without 
explicit  approval  of  the  Software  manager. 

10.  Use  of  the  "GOTO"  statement  is  prohibited  unless  explidtly  approved  by  the  Software 
Manager. 

11.  Units  that  contain  subunits  (i.e.  parent  units)  should  be  limited  to  structural  code  that 
primarily  invokes  the  subunits.  TTiis  technique  reduces  the  number  of  changes  in  the  parent 
unit,  and  therefore  recompilation  of  all  of  the  subunits.  It  also  keeps  the  parent  unit  at  a 
high  level  relative  to  that  of  the  subunits  which  improves  comprehension  of  the  resulting 
code. 

12.  Subprogram  calls  should  use  named  parameter  association  in  general.  For  example: 


PLOT  (  POSITIOM  «>  TARCET^XY,  COLOR  »>  RED  ); 


When  many  parameters  are  specified,  they  should  be  listed  one  parameter  to  a  line,  and 
aligned  under  the  first  parameter.  For  frequently  used  calls  (or  language  defined 
subprograms)  it  is  unnecessary  to  used  named  association.  Care  should  be  used  to  make  the 
names  appear  meaningful  and  not  provide  redundant  information. 

13.  Predefined  numeric  types  should  not  be  used  directly.  All  numeric  types  should  be 
derived  from  the  Universal  types. 

14.  Numeric  literals  other  than  0  or  1,  shall  not  appear  outside  of  declarative  regions.  (That 
is,  be  embedded  in  the  executable  subprogram  b^ies.)  Even  these  literals  will  only  appear 
if  they  are  used  to  initialize  or  increment  a  counter. 
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17.7  Naming  Conventions 

Names  should  be  selected  to  be  meanin^l  to  anyone  trying  to  read  the  code,  not  just  the 
original  designer.  This  implies  that  it  is  inappropriate  to  use  abbreviations  that  are  not 
clearly  understood.  Names  should  be  kept  under  20  characters  in  length  when  possible,  in 
recognition  of  the  fact  that  very  large  names  can  detract  from  comprehension  when  it  is 
difficult  to  understand  the  structure  because  of  clutter  caused  by  huge  names.  For  example; 


Item 

Good 

Poor 

List  of  targets 

TARCET_L1ST 

TCTLST 

Message  Suffer 

MSG.BUFFER 

MSGBF 

Mouse  (user  interface)  Report 

MOUSE.REPORT 

RAT_MSG 

Ethernet  Comnuni cat  ions  Driver 

NET.DRIVER 

ETHERMET_CO»WM  I  CAT  1 0MS_DR  I VER 

A  list  of  appropriate  "standard"  acronyms  and  names  should  be  maintained  for  each  project. 
Abbreviations  such  as  MSG  for  message  are  acceptable  provided  they  are  in  (or  added  to) 
the  project  list.  Consistency  should  be  maintained  among  all  of  the  developed  software  for  a 
project. 
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18.  Appendix  G  •  Sample  Timing  Budget 


Bordar  SystaM  •  Budgctad  Tiaat  for  Major  Procaaalng 

Avarage  TIm  par  Raquirad 

Ftfiction  Itarationa  Itaratlon  Tfiaa 

Name  par  second  (microsac)  (microsec) 


Receive  Rocket  Report  List 

10 

200 

2000 

Decode  Rocket  Report 

200 

800 

160000 

Compute  Rocket  Attitude 

200 

2000 

400000 

Encode  Rocket  Update 

200 

800 

160000 

Transmit  Rocket  Update  List 

10 

200 

2000 

Display  Rocket  Position 

200 

1200 

240000 

Receive  Target  List 

10 

200 

2000 

Display  Target  Position 

1000 

725 

1068000 

Receive  Mouse  Character 

175 

27 

4725 

Update  Cursor  Position 

35 

2000 

70000 

Process  Launch  Request 

2 

500 

1000 

Update  Statistics  Display 

1 

1000 

1000 

TOTAL 

1767725 

Notes: 

1)  Total  time  indicates  greater  than  100*  utilization  for  a  single  processor. 

2)  *  of  interrupts/second  ■  20S 

3)  Total  activities/sacond  «  20A0 
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The  following  listing  is  an  example  of  a  time  stamp  trace  for  the  Rocket.Control  task.  It 
indicates  that  the  task  operates  on  an  accurate  100ms  periodic  basis  until  enough  rockets  are 
airl^me  so  that  it  begins  missing  deadlines  (marked  with  an  *). 


•*STP(0002}  Control  task  start  time  229934  Delta  • 
-*STP(0002)  Control  task  start  time  330111  Delta  • 
**STP(0002)  Control  task  start  time  429700  Delta  ■ 
•■STP(0002)  Control  task  start  time  530269  Delta  • 
•*$TP(0002)  Control  task  start  time  629862  Delta  * 
•■STP(0002)  Control  task  start  tlma  729451  Delta  * 
••STP(0002)  Control  task  start  tima  830020  Delta  « 
•*STP(0002)  Control  task  start  time  929610  Delta  > 
•'STP(0002)  Control  task  start  time  1029201  Delta 
•*tTP(0002)  Control  task  start  time  1129767  Delta 
•*tTP(00u2)  Control  task  start  time  1229360  Delta 
•*tTP(0002)  Control  task  start  time  1329925  Delta 
-*$TP(0002)  Control  task  start  time  1429517  Delta 
•■$TP(0002)  Control  task  start  time  1529107  Delta 
•*kTP(0002)  Control  task  start  time  1629676  Delta 
•'STP(0002)  Control  task  start  time  1729265  Delta 
•*$TP<0002}  Control  task  start  time  1828859  Delta 
■•$TP(0002)  Control  task  start  time  1929425  Delta 
•*STP(0002)  Control  task  start  time  2029015  Dc'fta 
*'tTP(0002)  Control  task  start  time  2129585  Delta 
--$TP()002)  Control  task  start  time  7229175  Delta 
■-STP(0002)  Control  tjsk  start  time  2328766  Delta 
-'STP(0002}  Control  task  start  time  2429333  Delta 
■"STP(0002)  Control  task  start  time  2528926  Delta 
'"STP(0002)  Control  task  start  time  2628516  Delta 
•*STP(0002}  Control  task  start  time  2729083  Delta 
*'STP(U002)  Control  task  start  time  2828673  Delta 
■'STP(0002}  Control  task  start  time  2929242  Delta 
-'tTP(0002}  Control  task  start  time  3028832  Delta 
*'STP(0002}  Control  task  start  tlsN  3128422  Delta 
•*tTP(0002}  Control  task  start  time  3228989  Delta 
-*$TP(0002)  Control  task  start  time  3328579  Delta 
''STP(0002)  Control  task  start  time  3428173  Delta 
•■STP(0002)  Control  task  start  time  3528740  Delta 
■'$TP(0002)  Control  task  start  time  3628331  Delta 
•'8TP(0002)  Control  task  start  time  3728900  Delta 
**STP(0002)  Control  task  start  time  3828491  Delta 
"STP(0002)  Control  task  start  time  3928081  Delta 
-'SrP(00u2}  Control  task  start  tlise  4026648  Delta 
-'STP(0002)  Control  task  start  tlma  4128239  Delta 
•*STP(0002)  Control  task  start  time  4227829  Delta 
-'tTP<0002}  Control  task  start  time  4329371  Delta 
•'STP(0002)  Control  task  start  time  4427989  Delta 
•*STP(0002)  Control  task  start  time  4528555  Delta 
•*tTP(0002)  Control  task  start  time  4628146  Delta 
•*STP(0002)  Control  task  start  tlma  4728713  Delta 


229934  microseconds 
100177  microseconds 
99589  microseconds 
100569  microseconds 
99593  microseconds 
99589  microseconds 
100569  microseconds 
99589  microseconds 

99592  microseconds 
100566  microseconds 

99593  microseconds 
100566  microseconds 
99592  microseconds 
99590  microseconds 
100568  microseconds 

99589  microseconds 

99594  microseconds 
100567  microseconds 

99590  microseconds 
100570  microseconds 

99589  microseconds 

99592  microseconds 
100567  microseconds 

99593  microseconds 

99590  microseconds 
100567  microseconds 
99590  microseconds 
100569  microseconds 

99589  microseconds 

99590  microseconds 
100567  microseconds 

99590  microseconds 

99594  microseconds 
100567  microseconds 

99591  microseconds 
100569  microseconds 
99591  microseconds 

99590  microseconds 
100567  microseconds 

99591  microseconds 

99590  microseconds 
101542  microseconds 
98617  microseconds 
100567  microseconds 

99591  microseconds 
100567  microseconds 
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--*TP<0002) 

Control 

took 

start 

tlM 

4828306 

Delta 

99594  microseconds 

— *TP(0002) 

Control 

task 

start 

tiM 

4927896 

Delta 

99590  microseconds 

— tTP(0002) 

Control 

task 

start 

tins 

5027487 

Delta 

99590  microseconds 

-»TP{0002) 

Control 

task 

start 

tfM 

5128054 

Delta 

100567  microseconds 

>-STP(0002} 

Control 

task 

start 

tins 

5227645 

Delta 

99591  microseconds 

--*TP(0002> 

Control 

task 

start 

tiM 

5328273 

Delta 

100628  microseconds 

--»TP(0002) 

Control 

task 

start 

time 

5427802 

Delta 

99530  microseconds 

”$TP(0002) 

Control 

task 

start 

time 

5527394 

Delta 

99591  microseconds 

--*TP<0002) 

Control 

task 

start 

time 

5634545 

Delta 

107152  microseconds 

--*TP<0002) 

Control 

task 

start 

time 

5727554 

Delta 

93008  microseconds 

--$TP(0002) 

Control 

task 

start 

time 

5827144 

Delta 

99590  microseconds 

--STP(0002> 

Control 

task 

start 

time 

5933623 

Delta 

106479  microseconds 

--$TP<0002) 

Control 

task 

start 

time 

6027303 

Delta 

93680  microseconds 

--STP(0002) 

Control 

task 

start 

time 

6127870 

Delta 

100567  microseconds 

--$TP(0002) 

Control 

task 

start 

time 

6233782 

Delta 

105912  microseconds 

--STPC0002) 

Control 

task 

start 

time 

6330899 

Delta 

97117  microseconds 

--$TP<0002) 

Control 

task 

start 

time 

6432494 

Delta 

101595 

microseconds 

--STP(0002) 

Control 

task 

start 

time 

6533338 

Delta 

100844 

microseconds 

-•$TP(0002) 

Control 

task 

start 

time 

6638533 

Delta 

105195 

microseconds 

--tTP<0002) 

Control 

task 

start 

time 

6740030 

Delta 

101498 

microseconds 

•<STP(0002) 

Control 

task 

start 

time 

6841556 

Delta 

101526 

microseconds 

— $TP(0002) 

Control 

task 

start 

time 

7029347 

Delta 

187791 

microseconds 

--$TP(0002) 

Control 

task 

start 

time 

7132627 

Delta 

103279 

microseconds 

•-STP<0002) 

Control 

task 

start 

time 

7242113 

Delta 

109486 

microseconds 

•-tTP<0002) 

Control 

task 

start 

time 

7417546 

Delta 

175433 

microseconds 

--$TP<0002) 

Control 

task 

start 

time 

7529064 

Delta 

111518 

microseconds 

-$TP(0002) 

Control 

task 

start 

time 

7635551 

Delta 

106488 

microseconds 

--$TP(0002) 

Control 

task 

start 

time 

7742059 

Delta 

106508 

microseconds 

-$TP(0002) 

Control 

task 

start 

time 

7919917 

Delta 

177857 

microseconds 

--$TP<0002) 

Control 

task 

start 

time 

8027722 

Delta 

107805 

microseconds 

--»TP(0002) 

Control 

task 

start 

time 

8141697 

Delta 

113975 

microseconds 

--$TP<0002) 

Control 

task 

start 

time 

8307434 

Delta 

165737 

microseconds 

-$TP<0002) 

Control 

task 

start 

time 

8423121 

Delta 

115687 

microseconds 

--$TP(0002) 

Control 

task 

start 

time 

8534182 

Delta 

111061 

microseconds 

-•$TP<0002) 

Control 

task 

start 

time 

8697240 

Delta 

163058 

microseconds 

--STP<0002) 

Control 

task 

start 

time 

8815014 

Delta 

117774 

microseconds 

--»TP(0002) 

Control 

task 

start 

time 

8928160 

Delta 

113146 

microseconds 

--$TP{0002) 

Control 

task 

start 

time 

9040253 

Delta 

112092 

microseconds 

--$TP<0002) 

Control 

task 

start 

time 

9205898 

Delta 

165646 

microseconds 

•-$TP(0002) 

Control 

task 

start 

time 

9321093 

Delta 

115195 

microseconds 

--»TP(0002) 

Control 

task 

start 

time 

9436134 

Delta 

115041 

microseconds 

--iTP(0002) 

Control 

task 

start 

time 

9592926 

Delta 

156792 

microseconds 

--$TP<0002> 

Control 

task 

start 

time 

9707996 

Delta 

115070 

microseconds 

--*TP<0002) 

Control 

task 

start 

time 

9823226 

Delta 

115230 

microseconds 

•-tTP(0002> 

Control 

task 

start 

time 

9938537 

Delta 

115311 

microseconds 

-$TP(0002) 

Control 

task 

start 

time 

10096715  Oelti 

1  • 

158178  microseconds 

••STP(0002) 

Control 

task 

start 

time 

10211935  Oelti 

115220  microaaconds 

•<STP(0002} 

Control 

task 

start 

time 

10327281  Oelti 

1  ■ 

115346  microseconds 

««»  * 
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19  Appendix  H  •  Border  Defense  System  Ada  Source  Code 


The  source  code  for  the  BDS  system  follows  in  alphabetical  order 
of  the  unit  names  (speciflcations  precede  bodies). 
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-I  UNIT:  BOS  Sptc  l  Body. 

Effacts:  InitiatM  aain  procassing,  loops  raeordtng  Idla  tlaia. 
'•|  Nodiflas:  Mo  global  data  is  Mdifiad. 

*•{  Raqufras:  Status. Initialize  be  called  before  Mouse. Initialize. 
**|  Raisas:  No  explicitly  raised  exceptions  are  propagated. 

-•(  Engineer:  T.  Griest 


-•*******•********  Distribution  and  Copyright  *••****•••*•••**•**••*•' 

*•  Derivation  :  LabTek  Border  Defense  System  VI .0 

—  This  Border  Defense  System  Software  inherits  the  LabTek  copyright. 
*•  The  following  copyright  must  be  included  in  all  software  utilizing 
'•  this  application  program. 

'•  Copyright  1989  by  LabTek  Corporation,  Uoodbridge,  CT,  USA 

••  Permission  to  use,  copy,  modify,  and  distribute  this 
'•  software  and  its  docunentstion  for  any  purpose  and  without 
'■  fee  ia  hereby  granted,  provided  that  the  above  copyright 
••  notice  appear  in  all  copies  and  that  both  that  copyright 
••  notice  and  this  permission  notice  appear  in  supporting 
••  docuaentation,  and  that  the  name  of  LabTek  not  be  used  in 
-•  advertising  or  publicity  pertaining  to  distribution  of  the 
••  software  without  specific,  written  prior  permission. 

••  LabTek  makes  no  represantstiorm  about  the  suitability  of 
••  this  software  for  any  purpose.  It  is  provided  "as  is" 

**  without  express  or  implied  warranty. 


**•  Disclaimer 


••  This  software  and  its  docuaentation  are  provided  "AS  IS"  and 
••  without  any  expressed  or  implied  warranties  whatsoever. 

'•  No  warranties  as  to  performance,  merchantability,  or  fitness 
*•  for  a  particular  purpose  exist. 

••  In  no  event  shell  sny  person  or  organization  of  people  be 
••  held  responsible  for  any  direct,  indirect,  consequantial 
••  or  inconsequential  damages  or  lost  profits. 

..M*«*MM*«*M**  end-prologue  ••**•••••••••••••••••••***•••*•* 


with  Config; 

with  Status; 

with  Types; 

with  Mouse; 

with  Rocket; 

with  Target; 

with  Inter rupt_Control; 

with  Nachine_Oapandent; 


global  configuration  parameters 
updates  statistics  usad 
global  types  definitions 
mouse  movement  and  rocket  latftching 
rocket  attitude  and  aimpoint  calculations 
generation  of  various  targets 
enabling  and  disabling  of  (all)  interrupts 
individual  pixel  plotting  for  EGA 
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with  TiM^Stanp;  —  rui  tiM  profiltr 

pragna  ELABORATE (Nousa,  Statua,  Interrupt.Control,  Tiaa.Staap); 

procadura  BOS  ft 

••  This  ia  the  main  prograai  for  tha  Bordar  Defense  System.  It  has  only 
•-  two  calts  which  are  of  any  importance,  i.a.,  the  other  cede  is  for 
-•  timing  purposes  only.  Tha  first  call  performs  initialization  of  lii-e  screen 
-•  statistics  descriptions  and  their  initial  values.  The  second  call  starts 
-•  the  mouse. 

use  Types;  -*  for  visibility  to 

pragma  PRIORlTY(Conf ig.bds_priority); 

COUNT  :  Types. WORD; 

SLOW  :  Types. UORO; 

begin 

Status. Initialize;  •*  print  screen  statistics 

Nouse. Initialize;  ••  must  be  done  after  status  signal 

loop  ••  done  with  initialization 

■-STP(OOOI)  BOS  main  time  ataiip 
SLOW  1; 

for  COUNT  in  1..2000  loop 
SLOU  : >  SLOU  >  1; 
end  looy; 
end  loop; 
end  w)S; 


••  these  two  variables  are  for 
■■  slowing  the  time  stamps 
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UNIT:  Config  Spec. 

Effects:  Provides  systea*Hide  configuration  constants. 
*-|  Modifies:  No  global  data  Is  laodlfled. 

•*|  Requires:  No  initialization  is  required. 

—  I  Raises:  No  explicitly  raised  exceptions  are  propagated. 
*-|  Engineer:  T.  Griest. 


--  Date  :  10-11-88 
--  Purpose  : 

--  This  package  contains  global  configuration  paraaieters.  It  Is  referenced 
--  for  ALL  parameters  which  are  likely  to  be  changed  during  systeai  maintenance. 

with  System; 

package  Config  is 

-•  The  following  two  constants  allow  the  space  needed  for  the  various  tasks  to 
-•  be  declared  in  bytes. 

byte  :  constant  :«  8;  --  8  bits 

bytes_per_storage_uni t  :  constant  :■  byte  /  Syatem.STORAGE^UNlT; 

--  Now  define  battlefield  area  perimeters 

meters_1n_battle.srea  :  constant  :■  A_000.0;  --  In  X  and  Y  direction 

meters_per_X_pixel  :  constant  :■  9.625;  --  rounded  up  to  nearest 

meters_per_Tjjixel  :  constant  :■  11.875;  --  Types. METER. 

max_pixels_in_battle_areo  :  constant  :■  meters_in_battle_area 

/  meters _per_X _pixel; 

max_sctive_synbols  :  constant  :«  200;  --  max  simultaneous  synbols 


--  Task  priorities  in  order  of  decreasing  urgency. 

--  NOTE:  MOUSE  IN_CHAR  has  no  priority  becausa  it  runs 
--  completaly  at  the  hardware  Interrupt  level. 

--  The  idea  implemented  here  is  that  all  the  Simulator  information  is 
--  of  higher  priority  than  the  actual  Bordar  Oafense  Systam  code, 
savejwiority  :  constant  :■  20;  --  Mouse_Buffer 

displayjM-iority  :  constant  :■  18;  —  Graphics 

track_data_priority  :  constant  :■  16;  --  Target 

raport_buf jiriority  :  constant  :■  9;  --  Siaailstor 

guide_buf _priority  :  constant  :•  9;  --  Simulator 

roek_sup_priority  :  constant  :■  8;  —  Simulator 

targ_sup_priority  :  constant  :•  7;  --  Simulator 

eontrol_priority  :  constant  :•  5;  —  Rocket 

gufdance_priority  :  constant  :*  6;  —  Rocket 
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track _priority  :  conatant  ;■  3;  —  Tarflat 
i4pdata_pr{orf  ty  :  conatant  :>  2;  Statua 
bda_priority  :  constant  ;■  1;  **  Main 


*-  define  entire  hi*res  screen  display  borders.  The  screen  is  divided  into 
-■  two  nain  sections.  There  is  the  battlefield  area  where  the  targets,  rockets, 
-•  and  reticle  are  allowed  to  move,  and  there  is  the  statistics  area  where  our 
current  statistics  will  be  displayed.  The  aiaxiasjs  nuiber  of  digits  allowed 
*•  in  any  statistics  displayed  is  statistics.length.  Between  the  statistics  and 
*■  the  battlefield  there  is  a  border. 


*•  define  entire  screen  constants 

entire_screen_loft  ;  constant  :■  0; 

entire  screen  right  :  constant  :>  639; 

entire_screen_top  :  constant  :>  0; 

entire_screcn_bottoiii  :  constant  :>  349; 

••  define  battlefield  display  borders  and  center. 

Sarrief ield_screen_left  :  constant  ;■  222;  -*  starting  (left) 

battlef ield_$creen^right  ;  constant  :■  638;  --  ending  (in  pixels) 

bettlef ield_screen_top  :  constant  :■  1;  --  starting  (top) 

battlafield_8creen_bottcni  ;  constant  i*  338;  —  -sndfng  (in  pixels) 

battlef ield_center_x  :  constant  :■  430; 

battlefield_center_y  :  constant  :■  169; 

*■  define  border  between  battlefield  and  statistics. 

border_left  :  constant  ;■  221;  --  starting  (left) 

border_right  :  constant  :»  639;  --  ending  (in  pixels) 

border^top  :  constant  :»  0;  -•  starting  (top) 

burder_bottam  :  constant  :■  339;  -•  ending  (in  pixels) 

••  define  statistics  display  borders. 

status_left  ;  constant  ;■  0;  —  starting  (left) 

status_right  :  constant  :■  220;  **  ending  (in  pixels) 

status.top  :  constant  :■  0;  **  starting  (top) 

status.bottoM  :  constant  :■  349;  --  ending  (in  pixels) 

*■  statistics.length  is  the  nunber  of  digits  allowed  in  any  status  field,  and 
--  8tats_title_max_length  is  the  max  minber  of  letters  any  particular 
•*  statistics  title  msy  contain. 

statistics.length  :  constant  :■  4; 

stats_title_MX_(ength  :  conatant  :>  11; 

■sx.targets  ;  conatant  :■  100;  —  total  targata 
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Mx.rocktts 

inttrval 

••  launch  attitude 

launch.azinuth 

launch_alevat1on 

kiU.radius 

end  Config; 


conatant  ;■  20; 
conatant  :■  0.100; 

conatant  :■  16384, 
constant  :■  16384, 

constant  :■  10.0; 


—  total  rockets 

••  basic  interval  is  lOOms 

..  straight  ahead  in  BAMS 

—  straight  in  BAMS 

—  10  Meters  x  10  aeters 
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*1  UNIT:  Control  task  subunit. 

"I  Effects:  Provides  overall  control  for  rocket  flight  and  display. 
**|  Modifies:  Updates  rocket  data  base  in  Rocket  body. 

■-|  Requires:  No  initialization  is  required. 

■-|  Raises:  No  explicitly  raised  exceptions  are  propagated. 

--|  Engineer:  T.  Griest. 


vith  Intern4>t_Control; 

uith  Grid_to_Pixel; 

with  Simulate; 

with  Target; 

with  Calendar; 

with  Engage; 

with  Ti(ne_Stamp; 

pragma  ELABORATEdnterrupt.Control,  Crid_to_Pixel, 

Simulate,  Target,  Calendar,  Engage,  Time_Stamp); 

separatelRocket) 

-•  The  Conii-ol  task  accepts  data  from  the  Rocket  Data  Link, 

provides  information  to  the  Display  task,  ctd  disperses  information 
to  each  of  the  gnitlarKe  task;:.  It  then  collects  the  computations 
of  the  guidance  tasks,  and  generates  a  g>viiiance  messej^e  to  Nt  sent 
••  bacK  to  the  Rocket  Data  Link 


task  body  Control_Typc  is 

use  Calendar;  --  for  operators 

use  Types;  -•  for  operators 

package  RDL  renames  Simulate. ROL;  -*  make  simulator  transparent 

dis_list_size  :  constant  :•  Conf ig.max_rockets; 

MOVE.NUMBER  :  Types. U0R0_IN0EX; 

-*|  to  update  display 

NEXT_ROCICET_MSG  :  ROCXET_MSC_TTPE;  "1  local  copy  of  input  mag 

NEXT^T.IRGET.LIST  :  Target.TARGET_OATA_LIST_TTPE;  —  |  local  copy  of  ir^ut  data 
GUIDE.MSG  :  RCX:keT_GUIDE_MSC_TYPE;  "I  local  copy  of  output  msg 

A1MP0INT_LIST  :  AIMPOINT_LIST_TYPE(Typea.ROCKET_INOEX_TTPE); 

"I  local  copy 

MOWE_ROCKETS  :  Oraphics.MOVE_LIST_TYPE{Typea.ROCXET_INOEX,TTPE>; 

MOVEJNOEX  :  Types. UOROJNOEX; 
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:  Shapes. PIXEL; 
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HSGJHOEX  :  Typ*s.WORO_IHOEX;  --|  o««d  to  indtx  1nco«<ng  report 

OU)_TIME_TAG  :  Types. MORO;  **1  to  filter  etele  reportt  out 

AMY__ACT1VE_R0CKETS  :  BOOLEAN  :■  FALSE;  -*1  ueed  to  i^dote  OLO_TINE_TAO 

ACrTvE.ROOttTS.ID  :  Types. ROCKETJHOEX_TYRE;  -|  holds  an  active  rockets  10 

NEXT^EMGAGED  :  Target. TARGET_10_TYPE; 

NEXT^ISEHGAGEO  :  Target. TARGET_IO_TYPE;  —  |  keep  treek  of  all  disengagements 

OISEMGAGED.LIST  :  array(Types.ROCKETJNOEX_TYPE)  of  Target. TARGET_IO_TYPE; 

0ISENGAGED_0N_PTR  :  Types. W0RD_INDEX; 

0ISENGAGE0_0FF_PTR  ;  Types. WORD JNOEX; 

D1SENGACED_ACK_PTR  :  Typea.UORO_IMOEX; 

AVAILABLE.ROOCET  :  Types.  WORD  JNOEX;  --|  possible  rocket  to  latSKh 

LAUNCHJENOING  :  BOOLEAN  :>  FALSE; 

LAUNCHJARGET  :  Target. TAR6ET_tO_TYPE; 

LAUNCH JOCKET  ;  Types. ROOCET.INOEXJYPE ; 

ROaCET_OESTROYED  ;  BOOLEAN; 

ROCXET^LAUNCHEO  :  BOOLEAN; 

STARTJIME  ;  Ca lender. TIME; 

DELAY  PERICX)  :  DURATION; 


begin 

for  I  in  R0CKET_H I STORY 'range  loop  '-j  initialize  track  data 
ROCKET_HISTORY(n.ACTIVE  :»  FALSE; 

DISENGAGEDJlSTd)  :*  0; 

end  loop; 

NEXT_ENGAGE0  :>  0; 

DISENGAGED  0N_PTR  :■  1;  "I  initialize  disengage  circle  ^jeue 

DISEHGAG£0_0FF_PTR  :«  T; 

DISEMGAGED_ACX_PTR  :«  1; 

OLDJIMEJAO  ;■  0; 

STARTJIME  :■  Ca  lender.  CLOCK; 

loop  -*1  hain  processing  loop 

begin  -- I  exception  block 

STARTJIME  ;•  STARTJIME  ♦  Conf ig. interval ; 

--tTP(0002)  Control  task  start  time 
ROCKETJESTROYEO  :■  FALSE; 

ROCKET_LAUNCHED  :»  FALSE; 

ANY_ACTIVE_ROCKETS  :■  FALSE; 

--  Rendezvous  with  buffer  task  to  get  next  rocket  message  from  sensor 
-•BTP(0003)  Control  rendezvous  uith  Report_Buf  start 
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ROL  •  Report_Buf .  Get_Report  (MEXT_ROCICET_MSC)  ; 

-■STP(0004)  Control  rendezvous  with  Report_Buf  end 

-  Rendezvous  to  Get  tsrget  list  frosi  target  trscker,  end  provide  it 

-  with  informetion  on  which  targets  have  been  engaged  and  disengaged. 

•  If  there  are  more  on  circular  disengage  queue,  send  another  to  tracker 

if  OISENGAGED_OFF_PTR  /*  DISEHGAG£D_OH_PTR  then 
NEXT_OISENGAG£D  :«  DISENGAGED_LlST(DtSENGAG£0_OFF_PTR}; 
DISENGAGED_OFF_PTR  DISENGAGED_OFF_PTR  ren  dis.list.size  1; 
else 

NEXT_OISENGAGEO  :«  0; 
end  if; 


*STP(0005)  Control  rendezvous  with  Treck  Oat  start 


Target .  T  rack_Data .  Get  (  NEXT_T  ARGET_L  I  ST ,  NEXTJNGAGED ,  MEXT_D  I SERGAGED  >  ; 
■-STP(0006)  Control  rendezvous  with  Track  Dat  end 


••  Check  if  Track  task  has  recognized  the  engage  request,  if  so  then 
••  it  is  safe  to  clear  it,  and  possibly  engage  another. 

if  NEXTJMGAGEO  /«  0  and  then 

NEXT_r  AflGET_L  I  ST  <  NEXT  JNGAOED ) .  ST  ATUS .  ENGAGED 
then 

NEXT_ENGAGE0  0; 
end  if; 


Check  to  see  if  last  disengage  request  was  acknowledged 

if  OISENGAGEQ_ACR_PTR  /«  0ISEMGAGED_0FF_PTR  and  then 
not  NEXT_TARGET_L I ST (D I SENGAGED_L I ST(D I SENGAGEO_ACK_PTR} ) . STATUS . ENGAGED 
then 

OISENGAGED_ACK_PTR  :»  DISENGACED_ACK_PTR  re*  dis_list_size  ♦  1; 
end  if; 


I  determine  which  rockets  have  been  expended,  and  delete  the*  fro*  screen 
I  (previously  active,  but  no  longer  in  report  list) 

MOVE_INOEX  :■  0; 

NSGJNOEX  :•  1; 

for  R(X3CET_I0  in  Types. ROa(ET_INOEX_TYPE  loop 

if  ROCKET_HISTORY(R<X3CETJO),ACTIVE  then 
if  NEXT_R0CKET_NSG.RCX:KET_L1ST(NSG_IN0EX).TIME_TAG  «  Ol.O_TINE_TAG  then 
ANY_ACT1VE_R0CKETS  :■  TRUE; 

ACTIVE_ROCXETS_IO  :■  ROCKET_IO; 

exit;  "  old  rocket  report 

end  if; 
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*•  look  at  most  rocant  rocket  report  Mssage  to  make  sure  rocket  is  still  alive 


if  NSG.tNOEX  <«  NEXT_IK)CICET_NSG.NUN_ROaCETS  and  then 

ROCKETJO  ■  lieXT_ROClCET_NSC.ROCaT_LlST<MSG_IIIOEX>.»OaCETJD 
then 

I«)CKET_HISTO(IY(ROCXET_1D>.POSIT10II_PAIR.ROCKET_OLD  :■ 

ROCICET_HlSTORY(ROCICET_lO).POSlT10N_PAlR.ROCICET_MEU; 

ROCKET_HISTORY(ROC)CET_lD>.POSIT10ll_PAlR.ROaCET_IIEW 

NEXT_ROaCET_MSG . ROCKET.LI STfMSG.I NOEX) .POSITION; 
ROCKET_HISTO«Y(ROC1CET_IO).POSIT10N_PAlR.TARttT_OLB  :■ 

ROCKET_H I STORY ( ROCKET.1 0 ) .PCS I T ION_PA I R . TARGET_NEU; 
R0CKET_HtST0RY(R0CICETJ0).POSIT10N_PAIR.TARGET_NEW  :« 

MEXT_TARGET_LIST<ROCICET_HISTORY(ROClCETJD>. TARGET). P0SIT10N_MEU; 
MOVEJNOEX  :«  NOVEJNOEX  *  1; 

HOVE^ROCICETS(MOVEJMOEX)  ;» 

<XY_0L0  »>  Grid_to_Pixel(ROaCET_HISTORY<ROCltET_IO>.POSITION_PAIR-ROC«T_OLD>, 
XY_MEW  ■>  Grid_to_Pixel <ROCICET_HlSTORY(ROCKET_ID) .P0S1TI0N_PAIR.R0CXET_MEU) , 
OBJECT  »  (Shapes. PIXEL^MOOE, Shapes. ROCKET), 

COLOR  s>  Graph ics.ROCKET.COLOR); 

MSGJMOEX  ;•  NSGJMOEX  1; 
else 

••  the  rocket  has  deceased,  put  it  in  the  list  for  erasure. 

PIXEL_POlMT  :■  Grid_to_Pixel<  —  get  last  point  in  pixel  value 
ROCKET^H  I STORY  <  ROCKET_I D ) . POS I T lON.PA I R . ROCKET_MEU ) ; 
ROCKET_HISTORY(ROCKET_IO).ACTIVE  :»  FALSE;  —  mark  as  inactive 
NOVE_INOEX  :«  NOVE.IHOEX  ♦  1; 

NOVE_ROCKETS(NOVE_INOEX)  ;• 

<PIXEL_POINT, 

PIXEL_POIMT, 

( Shapes . P I XEL.NOOE , Shapes . ROCKET ) , 

Graph i cs . background^col or ) ; 

AVAILABLE.ROCKET  :>  ROCKET.IO;  ••  save  if  decide  to  launch 

0 I SENGAGEO.L 1 ST(0 I SENGAGEO_ON_PTR ) : -  ROCKET.HI STORY (ROCKET.IO ) . TARGET ; 
0ISEMGA0ED_0N_PTB  ;■  OISEMGAGED_ON_PTR  real  dis_list_siie  ♦  1; 
Interrupt.Control .Disable; 

Status.STATUS_CONTROL(StatUS.AIRBORNE).OATA  :« 

Status. STATUS_CONTROl(Status.AIRBORNE>.OATA  •  1; 

St atus . STATUS.CONTROL ( Status . EXPENDED ) .DATA  :• 

Status. STATUS_CONTROL(Status.EXPENOEO).OATA  ♦  1; 

Interrupt^Control .Enable; 

ROCKET_OESTROYED  :«  TRUE; 
end  if;  --  found 
else 

rocket  slot  previously  inactive,  see  if  rocket  has  launchad 
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if  NSG_INOEX  <>  NEXT_R0CKET_MSG.NUM_R0C1CETS  and  then 
MEXT_ROCICET_HSG . ROCKET_L IST<NSG_IMOEX). ROCKET J 0  « 

ROCICET_ID 

then 

ROCKET  HAS  BEEN  LAUNCHED,  UPDATE  DATA  BASE 

ROCKET_HISTORY(ROCKET_ID)  :» 

(  TRUE.  --  ACTIVE 

LAUNCH_TARGET,  —  TARGET 

(  NEXT_ROCKET_NSG.ROCKET_L1ST(MSGJHOEX>.POS1T10M,  --  NEW 
NEXT_ROCKET_NSG.ROCKET_LIST(fiSG_INOEX). POSITION,  --  OLD 
HEXT_TARGET.LIST(LAUNCH_TARGET).POSIT10N_HEW,  --  NEW 
NEXT_TARGET_LIST<LAUNCH_TARGET),POSITION_NEW>  --  OLD 

); 

LAUNCH.PENOING  :>  FALSE;  ••  all  accounted  for 

MSGJNOEX  :«  NSG.INOEX  ♦  1; 

Inttfrrupt_Control .Disable; 

Status . STATUS.CONTROL ( Status .A I RBORNE ) .DATA  : « 

Status. STATUS_CONTROL(Status.AIRBORNE).DATA  1; 

Interrupt^Control .Enable; 

ROCKET_LAUNCHED  :■  TRUE; 
else 

AVArU8L£_ROCKer  :*  ROCK£T_/0; 
et.d  if;  ••  new  rocket  test 

end  if;  •-  active  test 

oinJ  loop;  rocket-id  loop  (scan  of  all  rockets) 


I  Update  Time  tag  for  next  message, 
if  ANY_ACTIVE_ROCKETS  then 

OLD _T I ME_TAG  : «  HEXT_ROCKET_HSG . ROCKET_L I ST (ACT I VE_ROCKETS_ID ) . T 1 ME_T AG 
end  if;  --  if  no  active  rockets,  don't  change  OLO_TIHE_TAG 


I  Get  guidance  tdsk(s)  working  on  finding  new  ainpoint  for  guidance  msg 

for  I  in  Types. UORD_INOEX  range  1..0istrib.nuR_guide_tasks  loop 
-•STP(0007)  Control  rendezvous  with  Guidanced)  start 
Rocket_Guide( I } . H i story( 

ROCKET_HISTORY(Distrib.guide_low(I}..Oistrib.guide_high(I))); 
••STP(0008)  Control  rendezvous  with  Guidanced)  end 
end  loop; 

I  update  status  information 

Interrupt_Control .0 isable; 
if  ROCKET_LAUNCHEO  then 

StatUS.STATUS.CONTROLCStatUS.AlRBORNE). DISPLAYED  :>  FALSE; 
end  if; 

if  ROCKET  LAUNCHED  or  ROCKET  DESTROYED  then 
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Status. STATUS_CONTROI.(StatUt.AIRBORNE).OISPLATEO  :»  FALSE; 

Status. STATUS_CONTROL(Status.EXPEMOEO).OtSPLArEO  :•  FALSE; 
Status.REQ^COUNT  :«  Status.REO.COUNT  *  1; 
if  Status. REO_COUNT  «  1  then 
••STP(0009)  Control  rendezvous  with  Status  start 
Status .Update . S < gna I ; 

•-STP(OOIO)  Control  rendezvous  Mith  Status  end 
end  if; 
end  if; 

1 nterrupt_Control .Enable; 

MSG_INOEX  :«  0;  ••  zero  index  for  creating  guidance  message 

-*  Now,  check  if  we  should  try  to  create  a  new  ROCKET.  Note  that 
*■  if  a  rocket  has  just  been  destroyed,  don't  try  to  fire  a  new  one 
■■  before  the  rocket  tracker  knows  that  it  has  been  disengiged.  Otherwise 
-■  it  is  likely  to  choose  a  target  other  than  one  that  is  closest. 

•  •  * 

if  not  LAUNCH.PENOING  and 

OISENGAGED_ACK_PTR  >  D1SENGAGED_0M_PTR  and  ••  all  have  been  ack'ed 
NEXT_ENGAGED  *0  **  engage  has  been  ack'ed 

then 

MEXT.EMCAGED  ;■  Engage<NEXT_TARGET_LIST); 
if  NEXTJNGAGED  >  0  then 
LAUNCH_ROCKET  ;«  AVAIUBLE.ROCKET; 

LAUNCN_TARGET  :«  NEXT_ENGAGEO; 

LAUNCH^PENOING  :•  TRUE; 
end  if;  ••  ready  to  launch 
end  if;  -•  not  pending  cheek 

"I  9«t  graphics  task  working  on  displaying  rockets 

--STP(OOII)  Control  rendezvous  with  Graphics  start 

Graphics. Oisplay.NovelGraphics. LOU,  NOVE_ROCRETS(1..MOVEJNOEX)); 

-•STP(0012)  Control  rendezvous  with  Graphics  end 

-'I  now  get  results  of  guidance  information 

for  I  in  Types. WORO.INOEX  range  1..0ittrib.nuB_guide_tasks  loop 
••STP(0013)  Control  rendezvous  with  GuidancelZ)  start 
Rocket.Guidel I ) .Hcxt_Guidanee( 

AINPOlNT_LIST(Distrib.guide_ldw<I)..Oistrib.guide_high(I))  ); 
-•STP(0014)  Control  rendezvoua  with  Guidance(2}  end 
end  loop; 


-•  Now  generate  new  guidance  message  and  send  to  Guide.Buf 

for  ROeXETJD  in  ROCKET_H  I  STORY 'RANGE  loop 
if  ROCKET  HISTORY(ROCKETJD).ACTIVE  then 
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MSG.INOEX  :«  HSG_1N0EX  ♦  1; 

GU I OE.MSG . ROCKET_GU 1 0E_L  I  ST (NSG.l NOEX )  : > 

(ROCKET_ID,AIMPOIMT_LlST(ROCICETJD)); 

tlsif  UUJNCH.PENDING  and  than 

ROCKET_ID  ■  LAUMCH_ROCICET  then 
HSG.INOEX  :■  MSG.IMOEX  ♦  1; 

-*  initiate  launch 

GUIOE_MSG.ROCKET_GU1DE_LIST(MSG_IMOEX)  ;»  <ROCICET_ID, 

( Conf i g . I aunch_az 1 ffluth , 

Conf  i  g .  t  atawh_e  I  evat  i  on)  ) ; 

end  if; 
tnc  loop; 

GU1DE_MSG.NUM_R0CKETS  :>  HSG_INOEX; 

--$TP(0015)  Control  rendezvous  with  Guide_Buf  start 
ROL.Guide_Buf .Put_Guide(GUIDE_MSG);  *■  send  new  guidance  message 
-•STP<0016}  Control  rendezvous  uith  Guide_Buf  end 

periodic  schedule 

OELAT^PERIOO  ;»  START_T1ME  ■  Calendar. Clock; 
if  OEUY^PERIOO  <0.0  then 
START_TIME  :»  Calendar .Clock; 
end  if; 

••$TP(0017)  Control  task  end  time 

delay  OEl AT_PERIOO; 

exception 
vhen  others  => 

0ebug_lO.Put_Line("Exception  in  Control  task*); 
end;  ••  exception  block 

end  loop;  "I  main  processing  loop 

end  Control_Type;  --  Rocket. Control  task  body 
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UNIT:  Distrib  Package  Spec. 

Effecta:  Providea  paraaieters  to  control  taak  arrays  and  work  lists. 
Modifies:  No  global  data  is  Modified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


with  types; 


--  DISTRIBUTION  CONTROL  PARAMETERS 


package  Distrib  is 

nuB_guide_tasks  :  constant  :»  1;  ••  for  now 

gu{de_low  :  constant  arrayf Types. WORO_INOEX  range  1..nus_guide_tasks) 

'  of  Types. U0R0_IND£X  ;*  <others»»1>; 
guide_high  :  constant  ar ray( Types. UORD.INOEX  range  1..nuni_9uide_tasks) 

of  Types. UORO^INDEX  :>  (others»20); 

end  Distrib; 
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UNIT:  Engage  Procedure  Spec. 

Effects:  Determines  if  Rocket  is  to  be  launched,  and  at  what  target 
Modifies:  No  global  data  is  modified. 

Requires:  Status  package  must  set  mode  and  airborne  couits. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  M.  Sperry. 


•'  The  ENGAGE  procedure  detennines  if  a  new  rocket  should  be  launched, 

--  and  if  so,  which  one  it  should  be.  This  is  based  on  the  NGOE,  either 
--  Manual  or  Automatic,  the  nudoer  of  rockets  already  in  flight,  and 
••  (when  in  Manual  mode)  the  LAUNCH  button  on  the  operator  console. 

--  This  routine  is  called  durirtg  every  rocket  control  task  iteration. 

-*  Returned  TARGET  paramter  is  ZERO  if  no  target  should  be  engaged, 

--  otherwise  it  indicates  the  selected  target. 

with  Target; 

function  Engage(TARGET_INFO  :  in  Target.TARGET_OATA_LlST^TYPE)  return 
Target. TARGET^I 0_T YPE ; 
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I  UNIT:  Engas*  Procedure  Body. 

)  Effects:  Determines  if  Rocket  is  to  be  launched,  and  at  what  target 
I  Modifies:  No  global  data  is  modified. 

I  Requires:  Status  package  must  set  mode  and  airborne  counts. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 

1  Engineer:  M.  Sperry. 


--  The  ENGAGE  procedure  determines  if  a  new  rocket  should  be  launched, 

■■  and  if  so,  which  one  it  should  be.  This  is  based  on  the  NODE,  either 
--  Manual  or  Automatic,  the  msdier  of  rockets  already  in  flight,  and 
*■  (when  in  Manual  mode)  the  LAUNCH  button  on  the  operator  console. 

--  This  routine  is  called  during  every  rocket  control  task  iteration. 

--  Returned  TAR^aET  parameter  is  ZERO  if  no  target  should  be  engaged, 

--  otherwise  it  indicates  the  selected  target. 

with  Interrupt_Control; 

with  Status; 

with  Mouse_8uffer; 

with  Types; 

with  Config; 

with  Shapes; 

with  Time_Stamp; 

pragma  ELABORATE(lnterrupt_Contro( ,  Status,  Nouse_Buffer,  Time_Starp); 

function  Engage(TARGET_INFO  ;  in  Target. TARGET_OATA_LIST_TYPE)  return 
Target.TARGET_IO_TyPE  is 

--  for  operators 
--  for  operators 

:  Types. WORD; 

:  Types. WORD; 

:  Types.METERS; 

:  Types.METERS; 

:  Types. WTERS; 

:  Types.METERS; 

:  Types.METERS  :*  Config. meters_{n_batt(e_srea; 

:  Types.METERS; 

:  Target. TARGET JDJYPE; 

begin 

"STP(0018)  Engage  start 

TARGET_I0  ;■  0;  ••  default 

if  Status. STATUS_CONTROL(Status.AIRBORNE). DATA  <  Config.msx.rockets  then 
if  Status. NODE  •  Status.NANUAL  than 
if  Nousa  Buffer. LAUNCH  then 


—  reticle  in  PIXEL  coordinates 
reticle  in  PIXEL  coordinates 
••  reticle  in  GRID  coordinates 
•-  reticle  in  GRID  coordinates 


use  Types; 
use  Status; 

RETICLE_X_PIXEL 
RETICLE_Y_PIXEL 
RET1CLE_X_GRID 
RETICLE_Y_CRID 
PREV_D I  STANCE 
DISTANCE.X 
DISTANCE_Y 
TOTAL.O  I STANCE 
TARGET  ID 


90- 


Demonstration  Project  Final  Report 


-*  read  ABS_X  and  ABS,.Y  in  Mouse_Buffer,  then  convert  to  METERS  types. 
••  Then,  find  closest  target  in  list  to  reticle,  and  give  it  back. 
Interrupt_Control .Disable;  ••  go  atonic  while  reading 

RETICLE_X_PIXEL  :»  Mouse_Buffer.MEW_ABS_X; 

RETICLE_Y_PIXEL  :»  Mouse_Buffer.MEU_ABS_Y; 

Nouse.Buffer. LAUNCH  ;>  FALSE; 

Interrupt_Control .Enable; 

RETICLE_X_GRID  :» 

Types . METERS( Types . METERSl RET  1 CL£_X_P IXEL- 

Config.battlef ield_screen_left)  • 

Types. METERStConf ig.meters_per_X_pixel )); 

RtTlCLE_Y_GRID  :» 

Types. METERS<Types.M£TERS(Config.battlefield_screen_botto«  - 
RETICLE_Y_PIXEL)  • 

Types  .METERSlConf  i  g.i«eter8_per_Y_pi  xel )) ; 

■■  This  loop  locates  the  closest  target  to  the  reticle  center 
for  ID  in  Types. TARCET_INOEX_TYPE  loop 
if  TARGETJNF0(ID).STATUS.ACT1VE  and  then 
not  TARGET_INFO( ID). STATUS. ENGAGED  then 
DISTANCE_X  :a  abs(RETICLE^X_GRID  -  TARGET_IMFO(ID).POSITION_.NEW.X> 
DISTANCE_Y  ;»  abs(RETICLE_Y_GRIO  -  TARGET JNFO(ID).POSITION_NEW.Y) 
if  DISTANCE_X  <«  Shapes. ret icle_X_error  and 
DiSTANCE_Y  <■  Shapes. ret icle_Y_error 
then 


TOTALED  I STANCE  ;■  Types. METERS<OISfANCE_X  *  DISTANCE_X)  ♦ 
Types.METERS<OISTANCE_Y  •  OISTANCE.Y); 
tf  TARGET_10  «  0  or  else  TOTAL_D I  STANCE  <  PREV_OISTANCi:  then 
PREV_OISTANCE  :«  T0TAL_D  I  STANCE; 

TARGET_ID  :»  ID; 

end  if;  --  dfstance/target  check 

end  if;  --  x  and  y  reticle  distance  check 

end  if;  --  active/not  engaged  check 


end  loop; 
end  if; 
else 


-*  launch  check 

■*  automatic  mode,  search  for  closest  Y  value 


for  ID  in  Types. TARGET_INOEX_TYPE  loop 
if  TARGETJNFO(ID).STATUS.ACTIVE  and  then 
(not  TARGETJNFOdO). STATUS. ENGAGED  and 
TARGET_INFO<ID).POSITION_NEU.Y  <»  DISTANCE_Y) 
then 


OISTANCE_Y  :■  TARGET_INFO(IO).POSITlON_NEW.r; 

TARGET_ID  :«  ID; 

end  if;  ••  active/not  engaged/closest  y  check 

end  loop; 

end  if;  *■  mode  check 

end  if;  --  nuitjer  of  rockets  check 

-■STP(0019)  Engage  end 
return  TARGET_ID; 
end  Engage; 
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"I  UNIT:  Graphics  Package  Spec. 

-•|  Effects:  Perfoma  all  updates  to  graphics  display. 

•-|  Modifies:  No  global  data  is  modified. 

Requires:  Screen  must  be  put  in  graphics  mode  by  rwtime  initialize. 
Raises:  QUEUE.ERROR  is  raised  if  no  rooai  for  move  list. 

Engineer:  T.  Griest  /  M.  Sperry. 


--  Date  ;  10-10-88 
--  Purpose  : 

The  Graphics  package  provides  the  interface  for  all  screen  display 
--  operations.  All  activity  is  performed  by  the  Display  task  which  insures 
--  that  the  display  is  updated  in  a  consistent  and  timely  (c.  100  msecs.) 

--  fashion.  The  shapes  supported  are  defined  in  the  Shapes  package. 

--  The  initialization  in  the  run-time  places  the  screen  in  high  resolution  a»de 
--  of  the  EGA's  possible  types  and  also  sets  it  to  write  mode  two.  The  pixel 
--  coordinates  passed  to  the  display  task  are  passed  as  an  array  of  records, 

--  where  the  PIXEL  conponent  is  in  screen  coordinates,  not  meters.  Pixels  are 
--  defined  in  high  resolution  mode  as  640  (x)  by  350  (y).  Note  that  the  y 
--  direction  is  positive  going  down. 

with  Types; 
with  Config; 
with  Shapes; 

package  Graphics  is 

stack_size  :  constant  ;■  8192;  --  In  bytes 


•  define  screen  and  graphics  constants 


sU>type  C0L0R_TTPE  is  Types. WORD;  --  range  0..63;  --  64  colors  on  EGA 


backgroird_color  : 
reticle_color  : 
border_color  ; 
status_color  : 
status_box_color  : 
rocket_color  ; 
target_color  : 

COLOR  TYPE 


constant  COLOR JTPE 
constant  COL0R_TYPE 
constant  COL0R_TYPE 
constant  COLOR^TYPE 
constant  COLOR_TYPE 
constant  COLOR_TTPE 
constant  array<Types.TARGET_CLASS_TYPE,  BOOLEAN)  of 
:«  ((6,  14),  (3,  11),  <2,  10),  (5,  13»; 


:•  0; 

—  black 

:■  4; 

--  red 

2; 

—  green 

T; 

”  white 

2; 

—  green 

9; 

—  light  blue 

--  different  color  for  engage  *  false/true  and  target  type 
no_process  :  constant  C0L0R_TYPE  :■  16;  --  don't  process  object  color 


-•  define  graphics  data  structures 
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type  t»NE_RECORO 
XY_OLO 
XY_HEW 
OBJECT 
COLOR 

end  record; 

type  MOVE_LIST_TYPE  i»  array  ( Types. MGfiO_IMOEX  range  <>)  of  MOVE_RECORO; 
type  PRIORITY_TYPE  is  (HIGH,  LOW); 

'»JEUE_£RROR  :  exception;  --  if  queue  over/ ixider flow 


is  record 
:  Shapes  PIXEL; 

:  Shapes. PIXEL; 

;  Shapes. oeJECT_TYPE;  -*  list  of  relative  offsets 

;  COLOR_TYPE;  --  if  >  15,  ignore  this  motion  request 


task  type  Oisplay_Type  is 

entry  MovelPRIORITY  :  PR10RITY_TYP£;  WORX_LIST  :  HOVE_LIST_TYPE); 
pragma  PRIORlTY(Conf ig.display_priority); 
end  Oisplay_Type; 

for  Display_Type'ST0RAGE_SI2E  use  IMTEGER(Conf ig.bytes_per_storage_unit  • 

stack_size); 

Display  :  Oisplay_Type; 

end  Graphics; 
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UNIT:  Griphics  Packag*  Body 

Ef facts:  Parforma  all  updates  to  graphics  display. 

Modifies:  No  global  data  is  laodifiad. 

Requires:  Screen  Must  be  put  in  graphics  Mode  by  runtiMe  initialize. 
Raises:  aUEUE_ERROR  is  raised  if  no  rooM  for  move  list. 

Engineer:  T.  Griest  /  H.  Sperry. 


GRAPHICS  PACKAGE  BOOT 


Date  ;  10-11-88 
Purpose  : 

The  purpose  of  the  graphics  package  body  is  the  inplementation  of  the 
display  task  on  an  EGA  board.  The  display  task  is  responsible  for  buffering 
the  various  tasks  that  want  to  draw  their  particular  syebol  and  the  screen. 
The  task  begins  by  waiting  for  a  work  requast  to  draw  a  syebol.  Then,  when 
a  request  comes  in,  it  is  put  on  a  queue.  The  queue  it  goes  on  is  a  function 
of  the  callers'  priority.  Then,  since  there  is  work  to  do,  it  processes  one 
symbol  on  the  list  and  rechecks  for  higher  priority  work  requests  until  no 
work  on  any  priority  is  left. 


with  Meehine_Oependent; 
with  lnterrupt_Control; 
with  Debug_I0; 
with  Tiine_Stamp; 

pragma  ELABORATElMachineJJependent,  lnterrupt_Contro(,  0ebug_10,  Tiine_Staep>; 
package  body  Graphics  is 
task  body  Oisplsy_Type  is 

use  Types;  --  needed  for  visibility  to  operator 

buffer_size  :  constant  :■  2S6; 

type  CIRCULAR_BUFFER  is  srray(Types.UORO_INOEX  range  0  ..  buffer_size  -  1>  of 

MOVE_RECORO; 


type  BUFFER.TYPE  is  record 
ON  :  Types. WORO.INOEX  :■  0; 

OFF  :  Types. WOROJNOEX  :>  0; 

DATA  :  C1RCULAR_BUFFER; 
end  record; 

SET_PRI0R1TT  ;  PRIORITY_TYPE  :■  PRIO«ITY_TYPE'FIRST; 

BUFFER  ;  array(PR10RITY_TYPE'FlRST..PRI0RITY_TYPE'LAST)  of  BUFFER.TYPE;  --  set  up  queues 

NO_UORK  :  BOOLEAN;  -  all  queues  empty? 

U0RK_REQUEST  :  NOVE.RECORO;  —  for  individual  processing 
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OBJECT  :  Shapes. 08 JECT_PTR;  --  current- object  to  fl»ve 


procedure  Write_To_Screen<WORK_REQUEST  :  NOVE_RECORO)  is 

A  procedure  which  positions  the  cursor  on  the  screen  (based  on  the  XT_NEW 
--  field  in  the  MOVE_RECORO),  then  prints  the  string  advancing  the  cursor 
--  after  each  character  is  printed.  The  string  is  printed  character  by 
--  character  to  ensure  that  there  are  no  dependencies  on  the  representation  of 
--  the  type  STRIMG. 

bagin 

Mach i ne_Dependent . Wr i te_Mode_0; 

Mach  i  ne_Dependent .  Pos  i  t  i  on_Cursor  <U0RIC_RE0UEST .  XY_MEW.X , 

U0«r_RE0UEST .XY_NEW.Y); 

for  I  in  1 .  .Conf ig.stats_title_(iiax_length  loop 
Mach i ne_Oependent . Wr i t e( UORK.REOUEST .OBJECT . TEXT_08 JECT ( 1 } . 

WORK_REaUEST .COLOR ) ; 

end  loop;  ' 

Mach i ne_Oependent .Wr i te_Mode_2; 
end  Wri te_To_Screen; 

proce<A're  Ense_Image<BASE  :  Shapes. PIXEL; 

ITEM  ;  Shapas.08JECT_PTR)  is 

-  A  pr  icecA^ra  desi<jna*i  to  calculate  absolute  coordinates  for  Put^Pi.xel  'ihile 
■  placing  he  pixel  in  the  backgnxjnd  color,  thus  erasi>ig. 

be^in 

•-$TP(0020)  Graphics. Erase_Iinage  start 
for  I  in  ITEM.all'range  loop 

Machine_Dependent.Put_Pixel(BASE.X  ♦  ITEM.all<I).X_OFFSET, 

BASE.Y  ♦  lTEM.all(I).Y_OfFSET, 
background_col or ) ; 

end  loop; 

--$TP(0021)  Graph ics.Erase_ImBge  end 
end  Erase_Iinage; 
pragma  INL1NE(ERASE_IMAGE); 


procedure  Drau_Image(BASE  :  Shapes. PIXEL; 

ITEM  :  Shapes. 08JECT_PTR; 

COLOR  :  COLOR_TYPE)  is 

--  A  procedure  designed  to  calculate  absolute  coordinates  for  Put_Pixel  while 
--  turning  on  the  pixel  in  the  given  color. 

begin 

-•STP(0022)  Graphics. Orau_Iinage  start 
for  I  in  ITEM.all'range  loop 

Machine_Oependent.Put_Pixel<BASE.X  ♦  ITEM.all<I).X_OFFSET, 
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BASE.Y  ♦  ITEK.alUD'.YjOFFSET, 
COLOR); 

end  loop; 

"$TP(0023)  Graphics. OraN_Image  end 
end  Draw^lMge; 
pravna  INLINE(DRAUJMAGE); 


procedure  Initialize_Border  is 

"  A  procedure  used  to  place  a  color  border  around  the  battlefield  limits. 

BOIDER  :  HOVE_RECORD; 

begin 

BORDER. OBJECT. PIXEL.OeJECT  :>  Shapes.OOT; 

OBJECT  :>  Shapes. OBJECT_PTR_TABLE(BQROER.OBJECT. PIXEL.OBJECT); 

BORDER. COLOR  :«  border_color; 

-■  draw  top  and  bottom  border 

for  I  in  Config.border_left,.Config.border_right  loop 
BORDER. XY_NEW  :■  {Types. COORD I MATE (l>,Config.border_top); 

Oraw_l fflage( BORDER . XY.NEU, OBJECT , BORDER . COLOR ) ; 

BOROER.XT_NEW  :>  ( Types. COORD I NATE (I), Config. border.bottom); 

D  raw^ 1 mage( BORDER . XY_NEU, 08 JECT , BORDER . COLOR ) ; 
end  loop; 

--  draw  left  side  and  right  side  border 

for  j  in  Conf ig.border_top..Config.border_bottaM  loop 
BORDER. XY_NEW  :«  (Conf ig.borderjeft, Types. COOROIHATEfJ)); 

Draw.t  mage( BORDER . XY_NEU .OBJECT , BORDER . COLOR ) ; 

BORDER. XY_MEW  :■  (Config.border_right,Types.COOROINATE(J)); 
Oraw_Image(BOROER .XY.NEW, OBJECT ,  BORDER . COLOR ) ; 
end  loop; 
exception 

when  others  »  Oebug_IO.Put_Line(''Exception  raised  in  Graphics. Initialize"); 
end  Initialize.Border; 


procedure  Enqueuei PRIORITY  :  PRIORITYJYPE;  NOVE.REQUEST  :  MOVE.RECORO)  is 

--  A  procedure  which  enqueues  a  HOVE_RECORO  onto  the  proper  priority  queue  for 
*■  later  processing.  May  raise  aUEUE_ERROR. 

0N_NEU  :  Types.UORD_IMOEX; 

begin 

>-STP(0024)  Grephics. Enqueue  start 

ON^NEU  :«  <BUFFER<PRIORITY).ON  ♦  1)  ram  buffer_size; 
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if  0N_NEW  >  BUFFER(PRIORITY).OFF  then 
raise  QUEUE.ERROR; 
end  if; 

Interrupt.Control. Disable;  ••  compiler  bug 

■UFFER<PRIORITY).DATA(ON_NEV)  :«  NOVE.REQUEST; 
Interru,Jt_Control  .Enable; 

BUFFER(PRIORITY).ON  :«  ON.NEW; 

••$TP(002S}  Graphics. Enqueue  end 
end  Enqueue; 
pragma  INLINE(Enqueue); 


procedure  Oequeue< PRIORITY  :  PRIORITY_TYPE;  MOVE_REQUEST  ;  out  HOVE_RECO«0)  is 
--  A  procedure  to  remove  a  NOVE_RECORD  for  processing.  Nay  raise  aUEUE_ERROR. 
OFF_NEU  :  Types. UORO.INOEX; 
begin 

--$TP(0026)  Graphics. Dequeue  start 
if  BUFFER(PRIORITY).OFF  »  BUFFGR(PR10RITY).0N  then 
raise  QUEUE.ERROR; 

!ind  if; 

[;FF_MEW  <BUFFER(PRIORITY).OFF  ♦  1)  rem  buffer_size; 

!nterrupt_Control .Disable;  ••  conpiter  bug 

.  r,‘E_REO<JEST  BUFFER<PRIORITY) .OATA(OFF_NEH); 
inl^rrupt^Control. Enable; 

BUFFER<PRIORITY).OFF  ;«  0FF_NEW; 

••$TP(0027)  Graphics. Dequeue  end 
end  Dequeue; 
pragma  INLIHE(Oequeue); 


••  Body  of  DISPLAY  TASK 


begin 


>IO_UORK  ;■  TRUE; 


.■4av.h  i  ne_Oependent .  I  ni  t  i  a  I  i  ze_Screen; 
Nachine_Dependent.wri te_Hode_2; 

Initial ize_Border; 
loop 
begin 

••STP(j028)  Graphics  task  start 
if  MO.WORK  or  Nove' COUNT  >  0  then 
•-STP(0112)  Graphics  accept  Nove  start 


--  hi -res  graphics 
--  go  to  write  mode  2 
-•  draw  battlefield  border 

'•  exception  block 


accept  NovelPRIORITY  ;  PRIORITY_TYP£;  WORK_LIST  ;  NOVE_LIST_TYPE)  do 
for  I  in  UORK_LIST'range  loop 

if  UORK_LIST(I).COLOR  <>  IS  then  --  process  this  syntel? 

Enqueuel PRIORITY,  UORK_LIST(I)); 
end  if; 
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•nd  loop; 

•nd  Move; 

--»TP(0113)  Graphics  accept  Move  end 
MO_WOBr  ;»  FALSE; 
end  if; 

--  Now  there  is  some  work  to  do,  see  if  any  left  on  highest  priority 

SET.PRIORITY  5»  PR 10RITY_TYPE' FIRST; 
loop 

if  BllfFER(SET_PR10RlTY).0M  /«  BUFFER(SET,PRIORITY).OFF  then 
0eqoeue(SET_PR10RITY,U0RK_REaJEST);  --  at  this  point,  requests  real 
case  WORK.REQUEST. OBJECT. OeJECT_NCOE  is 

when  Shapes. TEXT_M00E  «>  Write_To_Screen<WORK_REOUEST>; 
when  Shapes. PlXEL_M00E  ■> 

OBJECT  ;«  Shapes.OflJeCT_PTR_rABL£<WORr_R£a;£ST.OfljeCT.PIXEL_OBJECT); 
Erase_I*aae<UORIC_R£OUEST .XY_OLO,  OBJECT >; 

Oraw.Image  (M0fiK_R£OUEST.XY_MEU,  OBJECT,  UORK^REQOEST. COLOR); 
end  case; 

NO_HORX  :■  FALSE; 

exit;  '*  I**''*  “•  processed  a  re<^st 

else 

HO_WORK  ;■  TRUE;  default 

exTt  when  SET_PR10RITY  ■  PRIORITY.TYPE'UST; 

SET.PRIORITY  T»  PR10RITY_TYP£'SUCC<SET_PRI0R1TY); 
end  if; 
end  loop; 

exception 

when  QUEUE_ERROR  «»  null;  **  since  error  is  propagated  to  caller 

when  others  »> 

Oebug_IO.Put_Line<"Error  in  Display  Task"); 

—  exception  block 

--$TP(0029)  Graphics  task  end 
end  loop; 
end  Oisplay^Type; 


end  Graphics; 
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--|  IWIT:  Grid_to_P1x«l  Fiction  Spec. 

Effects:  Converts  battlefield  meters  X-Y  to  graphics  Pixel  X-Y. 

-•|  Modifies;  No  global  data  is  modified. 

-•|  Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

•*1  Engineer:  T.  Griest. 

with  Shapes; 
with  Types; 

function  Grid_to_Pixel(GRID  :  in  Types. POSIT I ON_TYPE)  return  Shapes. Pixel; 
pragma  INLINE{nrid_to_Pixel); 
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UNIT:  Grid_to_P1xel  Function  Spec. 

Effects:  Converts  bettlefleld  asters  X-Y  to  grephics  Pixel  X*r. 
Modifies:  No  global  date  is  Modified. 

Retires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


with  Config; 

with  Time_Stafflp; 

pragma  ELABORATE(Time_Stainp); 

*-  Translate  from  Battlefield  Grid  coordinates  in  meters  to  pixels 
--  on  the  screen.  This  means  applying  scale  factors  for  x/y  and 
-•  providing  offsets  to  battlefield  area  on  screen.  NOTE:  since 
--  battlefield. coordinates  have  0,0  in  lower  left;  and  graphics 
■*  coordinates  have  0,0  in  upper  left,  this  involves  a  transpose  of 
••  the  Y  axis  (thus  the 

function  Grid_to_Pixel(GRIO  :  in  Types. POS1TION_TYPE)  return  Shapes. Pixel  is 
use  Types; 

PtX  :  Shapes. PIXEL; 
begin 

•-$TP<0030)  Grid_To_Pixel  start 

PIX.X  :«  Config. battlefield^screen^left  ♦ 

Types. COOROINATEfGRIO.X  /  Types. METERS(Conf ig.meters_per_x_pixel )); 
PIX.Y  :>  Conf ig.battlef ield_screen_bottom  - 

Types. COORD I MATE (GR I D.Y  /  Types.METERS(Conf ig.meters J>er_y_pixel)>; 
•-  Was  previously  below  return  (1*04*89  MPS) 

**$TP(0031)  Grid_To_Pixel  end 
return  PIX; 
end  Grid_to_Pixel; 
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UNIT:  Guidanct  Task  Subunit 

Ef facts:  Calls  "Guida"  to  con^ta  next  rocket  afnpoint  for  every 
active  rocket  in  the  input  list. 

Modifies:  Mo  global  data  is  nodified. 

Requires:  No  initislization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


with  Guide; 

with  Tiine_Sta«>p; 

with  lnterrupt_Control; 

pravna  ELABORATECGuide,  Time_Stamp,  Interrupt_Control); 
separatee Rocket) 

Tesk  Type  GUIDANCE  is  used  to  create  an  array  of  tasks  which  compute 
■-  guidance  information  for  a  specified  nuiber  of  rockets. 


task  body  Guidance_Typc  is 


use  Types; 

NEXT^GUIOE.LIST 

NEXT_HISTORT_UIST 

first_rcx:ket_io 

LAST  ROCKET  ID 


--  for  operator  visibility 
:  AIMP0INT^LIST_nPE<1 .  .Conf ig.mox.rockets); 
:  HIST0RY_LIST_TTPE<1 . .Conf ig.max.rockets); 

:  Types.WORO_IMOEX; 

:  Types.UORO.INOEX; 


Guide  computes  new  aimpoint  for  rocket  based  on  previous  positions 
--  function  Cuide(POS  :  POSITION_PAIR_TTPE)  return  Typea.AIMPOINT_TTPE 

is  separate; 


begin 

loop  "I  main  processing  loop 

begin  exception  block 

-•STP(0032)  Guidance  task  start 

-*  Get  history  information  for  our  target/rocket  list  and  make  local  copy. 
-•  Index  of  history  array  is  ROCXET_ID.  The  entire  Guide_List  array  is 
*■  used,  even  though  many  of  the  entries  may  be  inactive.  The  engagement 
--  task  is  responsible  for  filtering  out  only  active  rockets  for  issuing 
*-  the  guidance  messages. 

-•tTP(0033)  Guidance  accept  History  start 
accept  History(HISTORY_OATA  :  in  MISTORr_LIST_TYPE)  do 
fIRST_ROCKET_IO  :»  HISTORY_DATA'f irst; 

LAST_ROCKET_lO  :■  HISTORY_OATA' lost; 

Interrupt.Control .Disable; 

NEXT_HISTORY_LIST(fIRST_ROCKET_IO..UST_ROCKETJD)  ;■  HIST0«Y_0ATA; 
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Interrupt_Cantrol .Enable; 
end  History; 

•-$TP(0034)  Guidance  accept  History  end 

process  list  to  create  guidance  infonsation 

for  ROCKETJO  in  FIRST_ROCICETJO..UST_ROCICET_IO  loop 
if  MeXT_HISTORY_LIST(ROCICETJO),ACTlVE  then 
MEXT_GUIDE_LISTCROaCETJD)  ;■ 

Gu  i  de(  HEXT_H  I STOR  Y_L  I  ST  (  ROCKETJ  D  > .  POS 1 T I  OH_PA  I R  )  ; 

end  if; 
end  loop; 

■•$TP(0035}  Guidance  accept  Next_Guidance  start 
accept  Next_Guidance(AINPOINT_LIST  :  out  AIMP01NT_LIST_TYPE)  do 
if  AIHPOIHT_LIST'firat  /■  FlRST_ROaCET_IO  or 
AIMPOIMT_LIST'loat  /«  LAST^ROCXET_IO 
then 

raise  GUIOANCE_LIST_ERROR; 
else  ' 

Interrupt_Control. Disable; 

AIMPOIHT_LIST  ;»  NEXT^GUIDE_LIST<FIRST_ROCKETJD..LAST_ROCXET_IO); 
Internjpt_Control  .Enable; 
end  if; 

end  Next_Guidance; 

••$TP(0036)  Guidance  accept  Next.Guidance  end 

exception 
Mhen  others  »> 

Oebug_IO.Put_Line<"Error  in  GUIDANCE  TASK"); 
end;  --|  exception  block 

--$TP(0037)  Guidance  task  end 

end  loop;  ''I  main  processing  loop 

end  Guidance_Type; 
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UNIT:  Guide  Function  Spec. 

-•|  Effects:  Computes  e  new  aiapoint  based  on  rocket/terget  positions. 
Modifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  required. 

--|  Raises:  No  explicitly  raised  exceptions  ere  propagated. 

•*1  Engineer:  T.  Griest. 


with  Types; 

function  GuidefPOS  :  Types.POSIT10N_PAIR_TYPE)  return  Types. AlMPOINT_TYPE; 
pragma  INLINE(Guide); 
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--|  UMIT;  Guide  FisKtion  Body. 

Effects:  Conputes  a  new  ainpoint  based  on  rocket/target  positions.  *■ 
Modifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  re^^ired. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

•*1  Engineer:  T.  Griest. 


with  Types; 
with  Math; 
with  Config; 
uith  Time.Stamp; 

pragaia  ELABORATE  (Math,  Time.Stamp); 

••  The  Guide  function  takes  the  most  recent  two  postions  of  a  rocket/target 
*■  pair,  and  coeputes  an  aimpoint  for  the  rocket  to  intercept. 

-•  Several  optimizations  are  used  to  provide  good  average  and  worst-case 
•'  performance: 

--  1)  Rough  approximations  are  used  when  the  rocket  is  more 

••  than  a  specified  closing.time  away  in  any  axis; 

2>  rather  than  using  a  composite  velocity  vector,  discrete 
••  velocities  and  distances  are  used  for  X,T,  and  Z  to  eliminate 
--  the  need  for  square  root; 

--  and  a  greatly  simplified  arctan  routine  is  used  to  approximate  (within 
--  5  degrees  of  accuracy)  the  arctan  function  using  a  simple  multiply. 

--  This  also  simultaneously  converts  the  fixed  point  type  to  BAMs  (see  Types). 


function  Guide(POS  :  Types. POSlTlCMi_PAIR_TYPE)  return  Types.AIMPOIMT_TYPE  is 
use  Types;  --  for  operators 

clisb.Point  ;  constant  :«  500.0;  --  climb  to  500  meters  altitude  first 

control_time  :  constant  :■  20;  -•  last  20  intervals  (2  seconds) 


type  AXIS.TYPE  is  (X,  Y  ,  Z); 

MAX.AXIS  :  AX1S_TYPE; 

MAX_0IST  :  Types. METERS; 

type  POSITIOM_ARRAY_TYPE  is  arr8y(AXIS_TYPE)  of  Types.l«TERS; 


TARGET  PCS  :  P0S1TI0N_ARRAY_TYPE; 


ROCKET_0ELTA  :  POSITIOM_ARRAY_TYPE; 
TARGET_DELTA  :  P0S1TI0N_ARRAY_TYPE; 
AX1S_0IST  ;  POSIT 10M_ARRAT_TYPE; 


0IST_XY  :  Types.METERS;  —  used  to  project  Z  on  X-Y 

S0_X  :  Types. L0MG_FIXE0;  --  for  squaring 


-104- 


Demonstration  Projett  Final  Report 


SQ_Y  .  ;  TypM.LONG_FIXEO; 

SO_XT  :  Types. LONG^FIXEO; 

X6XT_AIMP0IMT  :  Types.AIMPOIMT_TYPE; 

CLOSING.RATE  :  Types.NETERS;  --  METERS  per  interval 

CLOSING.TIME  :  Types. WORD;  -•  OMber  of  intervals 

NAX_CLOSING_TIME  :  Types. WORD;  *-  worst  case  nun  of  intervals 

begin 

**STP(0038}  Guide  start 

--  First  determine  if  rocket  is  in  boost  phase  (initial  clinb  to  altitude), 

-*  if  so,  simply  maintain  clia6.  NOTE:  This  technique  assumes  that  the 
--  racket  wilt  never  fly  straight  and  level  below  the  cliRb_point.  This 
*•  implies  that  the  cliinb_point  is  sufficiently  high  that  the  ingress  phase 
**  has  a  constant  downward  slope.  If  this  turns  out  not  to  be  the  case, 

■*  the  rocket  will  junp  up  to  altitude  unexpeetantly  when  trying  to  fly 
"  level  below  tKe  climb_point.  The  expected  scenario  prevents  this 
from  happening.  However,  to  make  this  more  robust,  a  time_of_f light 
**  could  be  maintained  which  would  determine  when  to  conplete  the  boost 
-■  phase. 

R0CKET_DELTA<2)  ;«  POS.ROCKET_MEW.Z  -  POS.ROCKET.OLO.Z;  -  rocket  change  in  Z 
if  ROCJC£T_OELTA(2)  >«  0.0  and  POS.ROCXET_MEW.2  <  climb JWint 
then  *■  still  in  boost 

NEXT_A1HP01NT  :«  (Conf ig.  launch_azimuth,  Config.  lauKh^elevation); 
else  •*  must  do  some  guidance 

-■  Now  determine  how  far  away  the  target  is  in  each  axis 

AXIS_DIST(X)  :*  P0S.TARGET_MEW.X  -  POS.ROaCET_NEW.X;  --  target/rocket  X 
AXIS_OIST<Y)  :»  POS.TARGET_MEW.Y  -  P0S.R0C1CET_MEU.Y;  —  target/rocket  Y 
AXIS_OIST(Z)  :«  POS.TARGET_NEW.Z  -  POS.ROCICET_MEW.Z;  --  target/rocket  Z 

ROCXET_DELTA(X)  POS.ROCKET.NEU.X  •  POS.ROCKET.OLO.X;  ••  rocket  change  X 
ROCKET_OELTA(Y)  :■  POS.ROCKET_MEU.Y  -  POS.ROCKET_OU).Y;  —  rocket  change  Y 

TARGET_OELTA(X)  :■  POS.TARGET_MEU.X  -  POS.TARGET_OLO.X;  —  TARGET  change  X 
TARGET_DELTA(Y)  ;»  POS.TARGET_NEU.Y  -  POS.TARGET_OU>.Y;  --  TARGET  change  Y 
TARGET_OELTA(Z)  :«  POS.TARGET_MEW.Z  •  POS.TARGETjOtO.Z;  —  TARGET  change  Z 

Compute  the  farthest  distance  "MAX^DIST*  and  the  closing  rate  for  that 
••  axis. 

MAX_Ct.OSING_TIME  ;«  -1; 
for  AXIS  in  AXIS.TYPE  loop 

CLOSING.RATE  :>  ROCt(ET_DELTA(AXtS)-rARGEr_OELrA(AXrS); 

■*  make  sure  next  calculation  will  not  overflow  METER  type 

if  CLOSING.RATE  /•  0.0  and  aba  AXIS.OIST(AXIS)  <  SOO.O  then 
CLOSING.TIME  :>  Types. U0R0(AXlS_DIST(AXIS)  /  CLOSING.RATE); 
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if  CLOSINC_TIME  <  0  then 
NAX_CL0S1MC_TIME  ;■  Types.WORD' lest; 

else 

if  CLOSII(G_TIME  >  MAX_CL0SI«G_T1HE  then 
NAX_C10S1NG_T1HE  ;»  CLOSIMG.TIME; 
NAX_AXIS  ;«  AXIS; 
end  if; 
end  if; 
end  if; 
end  loop; 


--  Conpute  nuifcer  of  intervals  before  target/rocket  intercept. 

--  Mote:  this  operation's  accuracy  depends  on  the  rounding  algorithm  used... 

--  If  the  Rocket  is  close  (in  time)  to  the  Rocket,  do  extra  work 
*•  of  extrapolating  the  Targets  position  at  intercept 

if  MAX_CLOSING_TIME  >  0  and 
MAX_CL0SIM5_TIME  <  control_time  then  --  extrapolate 
AXIS_DIST<X)  ;«  AXIS_OIST(X)  ♦  TARGET_OELTA(X)*IMTEGER(MAX_CLOSIMG_TIME); 

AXIS_DIST(Y)  :»  AX1S_0IST(Y)  ♦  TARGET_OELTA<r)*INTEGER(MAX_ClOSIMGJlME); 

AXIS_0IST{2)  :«  AXIS_0IST(2)  ♦  TARGET_0ELTA<Z)*IMTEGER(«AX_C1.0SIMG_TIME); 

end  if; 

--  MOW  compute  angle  for  Azimuth  and  Elevation  to 

••  relative  target  position  (possibly  extrapolated)  for  this  rocket. 

MEXT^AIMPOIMT. AZIMUTH  ;■  Math.Arctan(AXIS_OIST(X),AXIS_DIST(Y)); 

sa_X  ;■  Types. LOMG_FIXEO(AXIS_OIST(X)); 

S<J_X  :=  Types. LOMC_FIXEO(SQ_X  *  Sa_X); 

SO_Y  ;«  Types. LOMC_FIXED(AXIS_OIST(Y)); 

SO_Y  :»  Types. LOMG_FIXEO(SO_Y  *  SQ_Y); 

SO_XY  :»  Math.Sqrt(SQ^X  ♦  SQ_Y); 
if  SQ_XY  >  4000.0  then 

MEXT_A1MP0IMT. ELEVATION  ;■  -200;**fly  almost  level  till  rocket  gets  closer 
else 

0IST_XY  :»  Types.METERS(SO_XY); 

MEXT_A I MPOIMT. ELEVATION  ;■  Math.Arcton(OIST_XY,AXIS_DIST(Z)); 
if  NEXT.AIMPOIMT. ELEVATION  >  -1024  then 
MEXT.AIMPOIMT. ELEVATION  :>  -1024; 
elsif  MEXT^AIMPOIMT. ELEVATION  <  -16384  then 
MEXT^AIMPOINT. ELEVATION  :■  -16384; 
and  if;  --  elevation  check 

end  if;  --  S0_XY  too  big  cheek 

end  if;  --  no  longer  in  boost  check 

-STP(0039)  Guide  end 
return  MEXT_AlNPOIMT; 
end  Guide; 
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I  UNIT:  Guid«_Buf  Task  Subunit 

I  Effects:  Provides  asynchronous  cons,  between  simulator  and  Control. 
I  Modifies:  No  global  data  is  modified. 

I  Requires:  No  initialization  is  required. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 

I  Engineer:  T.  Griest. 


**  The  Guide_Buf  task  acts  as  a  buffer  between  the  rocket  data  link 
support  task  Rock_Sup  and  the  Rocket. Control  task  which  processes 
--  the  rocket  data. 

--  TIMING  CONSIDERATIONS:  Guide_Buf  will  only  provide  the  most  recent 
-*  message  received.  If  two  messages  are  received  prior  to  one  being 
--  taken,  the  first  will  be  lost. 

with  Oebug_IO; 
with  Time^Stamp; 

pragma  ELABORATE(Oebug_IO,  Time_Stamp); 
separate  (Simulate. ROD 
task  body  Guide_Buf_Type  is 
use  Types; 

GUIDE_MSG  :  Rocket. ROCKET_GU I 0E_MS0_TYPE; 

HSG_COUNT  :  Types. WORD  :«  0;  *•  if  a  message  has  been  buffered 

begin 
loop 

"STP(0040}  Guidebuf  task  start 
select 

accept  Put_Guide(DATA  :  in  Rocket. ROCKET.GU I OE.HSG.TypE)  do 
•-tTP<0041)  Guidebuf  accept  Put.Guide  start 

GUIDE_NSG.NUN_ROCXETS  .—  OATA.NUM.ROCKETS;  —  copy  data 

for  I  in  Types. W0R0_IN0EX  range  1..0ATA.NUN_ROCXETS  loop 
GUIDE_MSG.ROCKET_GUI06_LIST(I)  :•  OATA.ROCKET_GUIOE_LIST( I ); 
end  loop; 

NSG_C0UNT  :■  1;  --  only  meaningful  that  it  is  >  0 

'•STP(0042)  Guidebuf  accept  Put.Guide  end 
end  Put_Guide; 
or 

when  MSG.COMT  >  0  » 

accept  Get_Guide(DATA  :  out  Rocket. ROCKET_GU I OE.MSG^TYPE)  do 
••STP(0043}  Guidebuf  accept  Get_Cuide  start 
DATA.NUM_ROCKETS  :«  GUIOE_NSG.NUM_ROCKETS; 
for  I  in  Types. U0R0_IN0EX  range  1..GU1DE_NSG.NUM_R0CXETS  loop 
OATA.ROCICET_GUIOE_LIST(I)  :«  GUIDE_MSG.ROCKET_GUIOE_11ST(I); 
end  loop; 
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MSG_COUNT  :*  1;  --do  keep  Multiple  copies 

--$TP(0044)  Guidebuf  accept  Get_Guide  end 
end  Get.Guide; 
end  select; 

'-$TP(0045)  Guidebuf  task  end 
end  loop; 
exception 
when  others  » 

Oebug_IO.Put_Line<"GlJIDE_BUF  tensination  due  to  exception."); 
end  Guide_8uf_Type; 
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I  UNIT:  lnterrupt_Control  Package  Spec,  and  Body. 

I  Effects:  Provides  controt  over  fnterrupc  flags. 

I  Modifies:  No  globel  data  is  modified. 

I  Requires:  No  initialization  is  required. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 
I  Engineer;  M.  Sperry. 


--  Date  :  11-09-58 
--  Purpose  : 

--  The  purpose  of  the  Interrupt_Contro(  package  is  to  provide  Ada  level 
--  semantics  for  disabling  and  enabling  interrupts  on  the  80X86  family  of 
--  processors.  Also  for  clearing  the  direction  flag  because  of  an  RTE  bug 
-•  Mhich  does  not  always  clear  it. 

with  Hach{ne_Code; 

use  Hachine_Code; 

pragma  ELABORATE(Hachine_Code); 

package  Interrupt_Control  is 

pragma  SUPPRESS(Elaboration_Check); 

procedure  Disable; 
pragma  INLINElOisable); 
procedure  Enable; 
pragma  INLINE(Eneble); 

procedure  Clear_Oireetion_Flag; 
pragma  INLINE(Clear_Oirection_Flag); 

end  Interrupt_Control; 

package  body  Interrupt.Control  is 

procedure  Disable  is 
begin 

MACH I NE_I NSTRUCT I ON ' (none , m_CL I) ; 
end  Disable; 

procedure  Enable  is 
begin 

MACH  I ME_I  NSTRUCT I ON ' { none . m_ST 1 ) ; 
end  Enable; 

procedure  Clear_Oirectian_Flag  is 
begin 

MACH  I NEJ  NSTRUCT  I  ON '(  none ,  m.ClD  )  ; 
end  Clear_Direction_Flag; 
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end  Interpupt_Control ; 
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•|  UNIT:  Machine_Oepenelent  Package  Spec. 

■|  Effects:  Provides  graphics  machine  dependencies. 

•|  Modifies:  No  global  data  is  modified. 

-|  Requires:  No  initialization  is  required  (other  than  graphics  mode). 
•|  Raises:  No  explicitly  raised  exceptions  are  propagated. 

-1  Engineer:  M.  Sperry. 


--  Date  :  11-04-88 
"  Purpose  ; 

--  The  purpose  of  the  Hachine_Oependent  package  is  to  provide  a  separate 
--  package  from  the  Ada  code  for  drawing  on  an  EGA  high  resolution  screen  via 
--  code  statements. 


with  Nachine^Code; 

with  Graphics;  . 

with  Types; 

use  Nachine_Code; 

pragma  ELABORATE (Mach ine_Code); 

package  Machine_Oependent  is 

procedure  Put_Pixel(ABS_X,  ABS_Y  :  Types. COORD (MATE; 

COLOR  :  Graph ics. COLOR JYPE); 

pragma  INLINE(Put_Pixel); 

procedure  Initialize_Sereen; 
pragma  INLlNE(Initialize_Screen); 

procedure  Write_Mode_0; 
pragma  INLINE(Urite_Mode_0); 

procedure  Positian_Cursor(X,Y  :  Types. COORD  I NATE); 
pragma  (NLlNE(Position_Cursor); 

procedure  Urite(CHAR  :  CHARACTER; 

COLOR  :  Graph ics.COLOR.TYPE); 
pragma  INLINE(Write); 

procedure  Urite_Mode_2; 
pragma  tNLINE(Write_Hode_2); 

end  Machine_Oependent; 
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UNIT:  N«ehin«_0«pend«nt  Package  Body. 

Effects:  Provides  graphics  machine  dependencies. 

Modifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  required  (other  than  graphics  mode). 
Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  N.  Sperry. 


package  body  Nachine_Dependent  is 


A  machine  dependent  package  which  makes  use  of  the  fteKtionelity  of  the 
Phoenix  BIOS  routines  to  perform  some  graphics  processing.  The  BIOS  call 
used  is  at  C000:0CD7  (which  is  INT  10  on  most  EGA  adapters). 


hi^res_graphics  :  constant 
set_cursor  ;  constant 
page_zero  :  constant 
write  function  :  constant 
index_register  :  constant 
access.register  :  constant 
mode_register  :  constant 
write^mode_2_v8l  ;  constant 
write_mode_0_val  :  constant 


16#10«: 

16M200#; 

16M0«; 

16ME«; 

16«3CE«; 

16«CFll(; 

5; 

2; 

0; 


->  graphics  mode 
—  set  cursor  function 
-*  set  cursor  to  active  page 

--  port  address 
>-  port  address 
--  index  register  5 


procedure  Put_Pixel(A8S_X,  ABS_Y  :  Types. COORD I MATE; 

COLOR  :  Graph ics.COLOR.TYPE)  is 

An  asseirbly  level  procedure  (for  enhanced  speed)  to  place  a  dot  on  the  EGA 
■-  screen,  write  mode  two  is  used  here  (again,  for  enhanced  speed).  It  is 
--  important  to  note  that  this  routine  is  called  more  frequently  that  any 
--  other, 

begin 


-*  The  first  thing  to  do  is  find  out  which  bit  must  be  turned  on.  This  is 

-•  done  by  taking  SHR(  80h,  ABS_X  mod  8  ).  The  bit  ordering  goes  from  7  •>  0. 

HACHINE_INSTRUCTION'(register_register,  m_MOV,  CX,  CX);  --  defeat  compiler  bug 

MACHINE_INSTRtJCTION'(register_iiiinediate,  m_M)V,  DX,  16«3CE*);  ••  select  bit 
NACHINE_INSTRUCTION'(register_inncdiate,  m_NOV,  AL,  8);  ••  mask  register 
NACHINEJNSTRUCTION'(register_register,  m_0UT,  DX,  AL);  •-  in  graphics  chip 

--  Determine  which  bit  must  be  turned  on.  This  is 

*■  done  by  taking  SHR(  80h,  ABS_X  rem  8  ),  reversing  the  bit  ordering. 

NACNINEJNSTRUCTION'(register_system_address,  m.NOV,  CX,  ABS.X' address);  --X 
NACHIHE_INSTRUCT10N'(register_register,  m_H0V,  BX,  CX);  --  make  copy  of  X 
NACHINEJNSTRUCTION'(register_{fliMdiste,  m_AND,  CL,  7);  ••  mask  for  bit  # 
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NACHINE_INSTRUCTION'(register_inntdfate,  n_NOV,  AL,  16#80i);  *■  most  significant  bit  is 
NACH:NE_INSTRUCTlON'(registar_ragister,  AL,  CL);  *•  bit  zero,  do  bit  reversal. 

•*  AL  noM  holds  the  bit  mask.  Now  give  it  to  the  bit  nask  ragister  located 
-  at  16#3CF#. 

MACH  I  NE_IMSTRIJCT  I  ON ’(register,  m_lNC,  OX);  --  increment  port  address  to  3CF 
NACHINEJNSTRUCTlON'(register_register,  n.OUT,  OX,  AL); 


**  Now,  latch  the  byte  of  graphics  memory.  The  byte  to  latch 
--  is  defined  as  (ABSJf  *  80)  ♦  <ABS_X  /  8).  Then,  when  giving 
*■  it  back,  place  the  color  in  AL.  Note  that  only  four  bits  of  the  color  are 
*•  significant  and  that  the  color  placed  in  AL  is  not  actually  a  color,  but  a 
--  palette  register  selection  (from  0  to  15).  The  color  in  the  palette 
-*  register  is  the  color  displayed. *16*6000#  is  loaded  (>  AOOOH) 
to  point  to  the  EGA  graphics  page  zero  mesiory  address. 

NACHINE_lNSTRUCTION'(register_systeffl_addreas,  n_M0V.  AX,  A8S_Y'address); 
MACHlNEjNSTRUCTION'lregisterJimiediste,  m^MOV,  CX,  80);  •*  bytes/line 
NACHINEJNSTRUCTION' (register,  m_MUL,  CX);  --  ABS_Y  •  80  in  AX 
NACHINE.tNSTRUCTtON'Cregister^imiiediate,  mjnv,  Cl,  3);  **  Shift  Count 
NACHtNE_INSTRUCTlON'<register_register,  m_SHR,  BX,  CL);  -  ABS_X  /  8  in  BX 
MACHINE_tNSTRUCTION'<register_register,  n.ADD,  BX,  AX);  ••  BX  is  offset 
MACHINE.lNSTRUCTION'lregisterJnmediate,  m^MOV,  AX,  -IdBOOCO*);  ••  base  of  RAM 
NACHINEJNSTRUCTION' <register_register,  m_MOV,  ES,  AX); 

**  Latch  the  palette  selection.  Note  that  the  contents  of  AL  upon  return  are 
**  meaningless,  and  that  the  color  is  latched  internally  to  the  EGA's  four  bit 
■*  planes. 

NACHINEJHSTRUCTION'(register_address,  m_MOV,  AL,  ES,  BX,  0);--  mov  al,es:ChxJ 
MACHINE_lNSTRUCTION'(register_system_sddress,  m.NOV,  AX,  COLOR 'address ); 

••  Finally,  give  the  palette  selection  (color)  to  the  four  bit  planes. 

MACHINE_INSTRUCTION'(address_register,  m.MOV,  ES,  BX,  0.  AL);**  mov  es:CbxI,a( 

end  Putjixel; 


**  Provide  a  mechanism  to  call  ROM  located  routine  to  initialize  screen 

procedure  IntIO;  **  spec  of  interface  to  BIOS  graphics  call 
pragma  INTERFACE(ASN86,  IntIO); 

pragma  INTERFACE_SPELLING( IntIO,  "D1BI0S7GRAPHICSCALL"); 


proeadure  Initial izejcreen  is 

-*  A  procedure  used  to  place  an  EGA  screen  into  mode  lOh,  which  is  640  x  350 
-*  pixels.  The  screen  is  initially  in  write  mode  0,  which  is  different  from 
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••  the  graphics  mode  10h.  Later,  in  Change_To_Mode_2,  the  write  mode  is 
••  changed  to  mode  2. 

begin 

MACHlNEJNSTRUCTlON'CregisterJmaediate,  m_HOV,  AX,  hi.res.graphics); 
MACHINEJNSTRUCTION'(none,  m.PUSHF); 

MACHlNEJNSTRUCT10N'(register_system_address,  m.CALL,  Int  10* Address); 
end  Initial {ze_Screen; 


procedure  Urite_Mode_0  is 

-•  A  procedure  used  to  change  the  write  mode  of  the  screen  to  mode  0,  for  text 
--  writing.  This  procedure  is  called  before  writing  the  necessary  statistics 
-•  titles. 

begin 

MACHINEJNSTRUCTION'CregisterJnmediate,  m.MOV,  DX,  index.register); 
NACHIMEJNSTRUCTIOH'lregisterJnaediate,  m.HOV,  AL,  mode_register); 
NACHIMEJMSTRUCTI0h'(regi8ter_register,  mjOUT,  OX,  AL); 

MACHINEJNSTRUCTION' (register Joiaediate,  m_MOV,  OX,  access.register); 
MACHlNE.INSTRUCTlON'lregister^iimediate,  ffl_HOV,  AL,  write_mode_0_val); 
MACHINE.INSTRUCTlCN'Cregister^register,  m^OUT,  OX,  AL); 
end  Write_Mode__0; 


procedure  Posit ion_Cursor(X,Y  :  Types. COORD I NATE)  is 
"A  procedure  used  to  place  the  cursor  where  necessary  (procedure  Write 
only  writes  at  the  current  cursor  position). 

begin 

MACHIHE_IMSTRUCTION'(register_imaediate,  m_MOV,  AX,  set.cursor); 
HACHINEJNSTRUCTION'(register_system_address,  m_MOV,  OL,  X'address); 
HACHINE_IHSTRUCTION'(register_system_address,  m_NOV,  OH,  Y'address); 
MACHINE_INSTRUCTION'(register_inaediate,  m_NOV,  BX,  paga.zero); 
HACHlNEJNSTRUCTION'(none,  m.PUSHF); 

MACHINE.INSTRUCTION'(register_system_address,  m.CALL,  Int 10' Address); 
end  Posit ion.Cursor; 


procedure  Write(CHAR  :  CHARACTER; 

COLOR  :  Graphics. COLOR.TYPE)  is 

••  A  procedure  used  to  place  the  character  CHAR  at  the  current  cursor  position 
on  the  screen  which  is  in  hi*res  graphics  mode,  write  mode  0.  This  proceAire 
uses  function  call  Oeh,  which  interprets  ascii  codes  10  and  13  as  linefeed 
••  and  carriage  return  respectively.  The  cursor  can  then  be  controlled  so  that 
••a  character  can  be  placed  anywhere  on  the  screen. 

begin 

NACHlNE.INSTRUCTtON'(registerJaiaadiate,  m.NOV,  AH,  write.function); 
HACHlME_IMSTRUCT10H'(register_sy8tam_address,  m.HOV,  AL,  CHAR 'address ); 
MACHlNE_lNSTRUCT10N'(register.systam_addrets,  m.HOV,  SL,  COLOR 'address); 
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HACHIME_IMSTRUCTION'(tione,  m.PUSHF); 

NACH I  NE_1  HSTRUCT I  ON '  (  ret)  <  ster_syst  en_address ,  n_CALL ,  Inti  0'  address  ) ; 
end  write; 


procedure  Write_Hode_2  is 

'•  A  procedure  used  to  change  the  write  mode  of  the  screen  to  mode  2,  for  pixel 
-•  plotting.  This  procedure  is  called  after  writing  the  necessary  statistics 
titles. 

begin 

MACHINE_.INSTRUCTION'(register_ianediate,  m_MOV,  OX,  index.register); 
MACHINE_lNSTRUCTION'(register_iiiinediate,  m_NOV,  AL,  mode^register); 
MACHIHEJNSTRUCTION'<register_register,  m_OUT.  OX,  AD; 
MACHlNE_lNSTRUCTION'(registe-_iinmcdiate,  m_HOV,  OX,  access.register); 
MACHlNE_INSTRUCTION'(register_inmediate,  m_MOV,  AL,  write_mode_2_val); 
MACMIME_IMSTRl/fcTION'<register_register,  m_0UT,  OX,  AD; 
end  WriteJ1ode_2; 

end  Machine^Oependent; 
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UNIT:  Nath  Package  Spec. 

Effects:  Conpute  various  functions:  Tan,  Arc  Tan,  and  Sqrt. 
Nodifies:  No  global  data  is  nodified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


with  Types; 
package  Nath  is 

function  Tan  (ANGLE  :  Types. SAM)  return  Types. LONG_FIXED; 
function  Sqrt(X  :  in  Types. METERS)  return  Types. METERS; 
function  Sqrt<X  :  in  Types.LONG_FIXEO)  return  Types. LONG_FtXED; 
function  Arctan(REL_X,  REL_Y  :  in  Types. METERS)  return  Types. BAM; 
end  Nath; 
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I  IMIT:  Nath  Package  Body. 

I  Effects:  Compute  various  factions:  Tan,  Arc  Tan,  and  Sqrt. 
I  Nodifies:  No  global  data  is  modified. 

I  Requires:  No  initialization  is  required. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 

I  Engineer:  T.  Griest. 


uith  Tiine_Stamp; 

pragma  EUBORATElTime.Stamp); 


package  body  Math  is 
use  Types; 


TAN_TASLE  :  array(Types.WORO  range  0,.90)  of  Types. LOHG^FIXED  :« 

< 


0.00000, 

0.01746, 

0.03492, 

0.05241, 

0.06993, 

0.08749, 

0.10510, 

0.12278, 

0.U054, 

0.15838, 

0.17633, 

0.19438, 

0.21256, 

0.23087, 

0.24933, 

0.26795, 

0.28675, 

0.30573, 

0.32492, 

0.34433, 

0.36397, 

0.38386, 

0.40403, 

0.42447, 

0.44523, 

0.46631, 

0.48773, 

0.50953, 

0.53171, 

0.55431, 

0.57735, 

0.60086, 

0.62487, 

0.64941, 

0.67451, 

0.70021, 

0.72654, 

0.75356, 

0.78129, 

0.80978, 

0.83910, 

0.86929, 

0.90040, 

0.93252, 

0.96569, 

1.00000, 

1.03553, 

1.07237, 

1.11061, 

1.15037, 

1.19175, 

1.23490, 

1.27994, 

1.32704, 

1.37638, 

1.42815, 

1.48256, 

1.53986, 

1.60033, 

1.66428, 

1.73205, 

1.80405, 

1.88073, 

1 .96261 , 

2.05030, 

2.14451, 

2.246C4, 

2.35585, 

2.47509, 

2.60509, 

2.74748, 

2.90421, 

3.07768, 

3.27085, 

3.48741, 

3.73205, 

4.01078, 

4.33148, 

4.70463, 

5.14455, 

5.67128, 

6.31375, 

7.11536, 

8.14434, 

9.51436, 

11.43005, 

14.30067, 

19.08114, 

28.63625  ,  57.28996,  Types. sqrt_large_nijflber); 


function  Tan  (ANGLE  :  Types. BAM)  return  Types. LONG_FIXED  is 
TANGENT  :  Types.LONG.FIXEO; 

THETA  :  Types. WORD; 

■■  procedure  Ounny  is  begin  null;  end;  ••(UNIX) 

•begin 

-•$TP(0048)  Math. Tan  start 

THETA  :«  Types. W0R0(ANGLE/182);  ••  approx.  182  bama  per  degree 

if  THETA  >■  -90  and  THETA  <■  90  then 
if  THETA  >■  0  then 
TANGENT  :>  TAN_TABLE(THETA); 

else 

Ouiiiiy;--(UNIX) 

TANGENT  ;■  •TAN_TABLE(-THETA); 
end  if; 

elsif  THETA  <  -90  then 
TANGENT  :»  TAN_rABLE(THETA  ♦  180); 

else 

TANGENT  :•  -TAN.TABLEdOO-THETA); 
end  if; 

••BTP(0C49>  Math. Tan  end 
return  TANGENT; 
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tnd  Tan; 


fixwtion  SqrtCX  :  in  Types. HETERS)  return  Types. METERS  is 
use  Types;  *■  import  operators 
F  :  Types. METERS  ;«  X; 

Y  :  Types. METERS  ;»  1.0; 

OLD_Y  !  Types. METERS  :«  Y; 

bepin 

--STPTOOSO)  Math.Sqrt  start  (METERS) 
for  I  in  1..15  loop 
exit  utien  Y  *  0.0; 

Y  ;»  (  Y  ♦  Types. METERS<F/Y)  )  /  2; 
if  Y  »  0L0_Y  then 

exit; 
end  if; 

OLO.Y  ;»  Y; 
end  loop; 

--STP(0051)  Math.Sprt  end  (METERS) 
return  Y; 
end  Sqrt;, 

function  Sqrt(X  s  in  Types.LOMC^FIXEO)  return  Types.LONG_FIXED  is 
use  Types;  ••  import  operators 
F  :  Types.LONG.FIXED  :«  X; 

Y  :  Types.L0NG_FIXE0  :»  1.0; 

OLD_Y  :  Types.LOHC_FIXEO  :«  Y; 

begin 

■-STP(0052)  Math.Sqrt  start  (IOMG_FIXEO) 
for  I  in  1..15  loop 
exit  when  Y  •  0.0; 

Y  ;»  (  Y  ♦  Types.LONG_FIXED(F/Y)  )  /  2; 
if  Y  «  OLD_Y  then 

exit; 
end  if; 

OtO.Y  :«  Y; 
end  loop; 

-•STP(00S3)  Math.Sqrt  end  (LONG.FIXED) 
return  Y; 
exception 

Mhen  NUMERIC_ERROR  »>  Y  ;«  0L0_Y; 

return  Y; 

end  Sqrt; 


-  A  function  used  to  return  an  approximation  of  the  arctangent  function. 

■  The  meximua  error  allowed  is  five  degrees  off.  The  Arctan  ftewtion 

•  computes  the  arctangent  handling  each  quadrant  on  a  case  by  case  basis, 

-  since  one  general  algorithm  would  violate  the  maximua  error  condition. 
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function  Arct.n(REL.X.  REL.Y  :  in  Typw.HETERS)  return  Types.SAM  is 

type  BIC.FIX  is  delta  0.125  ranpe  -200.000.000.0  ..  200.000.000.0; 

offset  :  constant  Types.BAH  :•  2  *  182;  -  ti»  deprees  offset 
potote.45  :  constant  BIC.FIX  ;■  8192.0; 
potate.90  :  constant  BIC.FIX  :*  16384.0; 

rotate.135  :  constant  BIC.FIX  :■  24575.0; 

X  ;  BIC.FIX; 

Y  :  BIC.FIX; 

TEMP  :  BIC.FIX; 

ANCLE  :  Types. BAM; 

be^in 

— $TP{0054)  Math.Arctan  start 
X  :«  BIC.FIXIREL.X); 

Y  ;■  BIC.FIX(REL.Y); 

-•  Quadrants: 


♦/-180 


II  I  i 

III  I  IV 


--  low  45  decrees 


convert 


if  X  <  0.0  then  "  “ 

X  ;«  -X; 

if  Y  <  0.0  then  " 

Y  **  ^Y * 

if‘x  <.'y  then  -  W  45  deQrees 

X  :»  BIG.FIXtX  *  8192  /  Y); 

X  :■  rotate_45  -  X; 

X  :■  rotate.135  •  X; 

ANCLE  Types.8AM(-X)  -  offset; 

-•  low  45  decrees 

else 

TEMP  :•  X; 

X  Y;  - 

Y  ;«  TEMP; 

X  :■  BIC.FIXtX  •  8192/Y); 

ANCLE  :«  Types.BAMfX)  ♦  offset  ♦  Types.BAM'ffrst; 
end  if; 

else  -  " 

ifX<-Ythen  -  upper  45  degrees 

X  :»  BIC.FIX(X  •  8192/Y); 

Ai'CLE  ;«  Types. BAMCX)  ♦  offset  ♦  16384; 

—  low  45  degrees 

TEMP  :«  X; 

X  ;«  Y; 

Y  :•  TEMP; 

X  ;•  BIC.FIXCX  *  8192); 

X  ;•  BICJIXIX  /  Y); 

X  :■  rotate.45  •  X; 


119 


Demonstration  Project  Final  Report 


X  ;*-x  rot«te_135; 

ANGLE  :•  Types. BAM(X); 


end  if; 
end  if; 

else 

If  Y  <  0.0  then 
Y  :»  -Y; 

H  X  <■  Y  then 
X  :«  BIC_FIX(X  •  8192/Y); 

ANGLE  :«  Types.BAMfX)  ♦  offset 
else 

TEMP  :«  X; 


-  I  or  IV 

-  IV 

••  upper  45  degrees 


16384; 

--  low  45  degrees 


X  Y;  " 

Y  ;»  TEMP; 

X  :»  rotote_45  -  BIG_FIX(X  •  8192/Y); 

X  ;■  X  -  rotete_45; 


ANGLE  :■  Tvpes.BAM(X)  -  offset; 


end  if; 

else 

if  X  <  Y  then 

if  Y  -  X  >*  X  then 

X  ;«  rotate_45  ♦  (rotate_45  -  BIGJIXCX  *  8192  /  Y)); 


--  I 

—  i^per  45  degrees 


else 

X  ;»  BIG_FIX(X  *  8192  /  (X  ♦  Y)); 

X  ;»  rotate_45  ♦  X; 
end  if; 

ANGLE  :*  Types. BAM<X); 

••  low  45  degrees 

if  Y  •  0.0  and  X  «  0.0  then 
ANGLE  ;»  Types. 8AM<0); 


else 

TEMP  :»  X; 

X  ;»  Y; 
yl«  TEMP; 

X  :«  BIG_FIX<X  •  8192/Y); 

ANGLE  :»  Types.BAM(X)  ♦  offset; 
end  if; 
end  if; 


--  convert 


end  if; 
end  if; 

.•*TP(0055)  Math.Arctan  end 
return  ANGLE; 


end  Arctan; 
end  Math; 
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I  UNIT:  Mouse  Package  Spec. 

I  Effects:  Provides  graphics  pointing  device  intern^it  handling. 

I  Modifies:  Status  Mode,  and  Mouse.Buffer  X*Y  positions  are  updated. 
I  Requires:  Rintime  initialization  of  interrupt  vector. 

I  Raises:  Task  will  terminate  on  NOUSE_ERROR. 

I  Engineer:  M.  Sperry. 


••  Date  ;  9-30-88 
--  Purpose  : 

This  is  the  specification  for  the  package  mouse.  In  addition  to 
--  establishing  coonunications  with  the  mouse,  a  task  is  provided  which 
-•  handles  the  receive  interrupt  generated  by  the  snuse  at  CCM2. 

with  System;  pragma  ELABORATElSystem); 

package  Mouse  is 


procedure  Initialize; 

task  Char_In  is 
pragma  INTERRUPT_HAN0LER; 
entry  REPORT; 

for  REPORT  use  at  (16#83#,0);.  --  COMZ  8250  serial  port  vector 

end  Char_In; 

end  Mouse; 
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UNIT:  Mouse  Package  Body. 

•-|  Effects:  Provides  graphics  pointing  device  interrupt  handling. 

•*|  Modifies:  Status  Mode,  and  Mouse_Buffer  X*Y  positions  are  updated. 
>•(  Requires:  Rmtioie  initiaUzation  of  interrupt  vector. 

-*|  Raises:  Task  will  teminste  on  MOUSE_ERROR. 

■*|  Engineer:  M.  Sperry. 


--  Date  :  9-30-88 
--  Purpose  : 

Package  Mouse  provides  one  task  and  one  procedure.  The  proceckjre 
--  Initialization  sets  up  the  mouse  at  4800  baud,  no  parity,  7  data  bits,  and 
--  two  stop  bits.  The  nunPer  of  stop  bits  is  insignif icw:t.  There  should 
--  only  be  two  formats  that  the  mouse  can  be  in,  either  relative  bit  pad  one 
--  or  Micrsoft  Mouse.  The  default  on  power  up  for  the  mouse  is  MM  at  4800. 

--  The  mouse  must  be  comnanded  in  the  following  order:  BAUD  (which  is  set  to 
--  default  to  4800  so  it  is  not  necessary  to  reprogram  it),  #  of  reports/sec., 

--  and  then  formit  of  the  reports. 

with  Types; 
with  Low_Level_IO; 
with  Oebug^lO; 
with  Mouse^Buffer; 

with  Mouse^Oata;  -•  provides  constants  and  data  stnxtures 

with  Status; 

with  Interrupt_Control; 

with  Time_Stamp; 

use  Low_Level_IO; 

use  Mouse_Data;  ••  visibility  to  "end"  fvsKtion 

pragma  ELABORATE(Low_Level_IO,  0ebug_I0,  Mouse_Buffer,  Status,  Time_Staiip); 

package  body  Mouse  is 

DATA  :  l.ow^Level_10.8YTE;  --  char  from  mouse 

8UTTON_PUSHED  :  Nouse_Data.BIT_FIELD;  —  array  representing  keys 

STATUS_BYTE  :  Mouse_Data.BIT_FIEL0;  —  represents  status  errors 

PREV_BUTTON_PUSH  ;  Mouse_Data.BIT_FIEL0  ;■  (others  »>  FALSE);  —previous  buttons 
MOUSEJMPUT  ;  Mouse_0ata.RAU_MOUSE_W0«0  ;«  (0,0,0);--  transform  to  12-bit 

MOUSE_REPORT  ;  Mouse_Oata.SIGNEO_MOUSE_«ORO;  --  transformation  to  signed 

REP0«T_C0UMT  :  Types. WORD  range  0..5  :■  0;  —  coutts  byte  in  report 

CHANGE.REQUESTED  :  BOOLEAN  :■  FALSE;  --  rendezvous  with  status? 

MOUSE.ERROR  :  EXCEPTION; 

TEMP_X  :  Types. WORD;  --  local  copy  of  X  motion 

TEMP_Y  ;  Types. WORD;  --  local  copy  of  Y  motion 

procedure  Initialize  is 
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-•  A  procedure  used  to  initialize  the  mouse  to  4400  baud  and  Relative  Bit 
--  Rad  One  format. 

INTERRUPTS  :  Low_Level_IO.BYTE: 

RESPONSE  :  Low.Level.IO.BYTE; 

TIME.OUT  :  INTEGER  :>  30000; 

begin 

Receive_Control(Mouse_Data.COH2_status, RESPONSE);  -■  clean  out  junk  in  status 
Receive_Control(House_Data.COM2_dat8, RESPONSE);  -•  clean  out  junk  in  data 

Send_Control(Mouse_^Data.C0M2_control,Nouse_0ata.access_baud); 
Send_Control(Nouse_Oata.COM2_data,Mouse_Oata.host_baud);  set  BAUD  *  4800 
•*  set  COM2  serial  paraeteters 

Send_Cont  rol ( Nause_Da ta . C0M2_cont  rol, Nouse_Da ta . host_f ormat ) ; 
Send_Control(House_Data.caM2_data,Mouse_0ata. acknowledge);  -•  touch  mouse 
loop 

Receive_Control(Mouse_0ata.CaM2_status, RESPONSE);  *-  wait  for  response 

if  RESPONSE  >  Mouse_0ata.data_,new  then 
Receive_Control(Mouse_0ata.C0H2_data, RESPONSE);  --  clear  out  byte 

exit; 
else 

TIME.OUT  ;«  TIME.OUT  •  1; 
end  if; 

if  TIME_0UT  »  0  then 
exit; 
end  if; 
end  loop; 

if  T1ME_0UT  «  0  then 

Debug_IO.Put_Line<"Unable  to  establish  conmunications  with  mouse."); 
end  if; 

Send_Cont  roll Nou8e_0at e . C0M2_dat a , Mouse_0at a . mouse^char^speed) ; 

delay  0.01;  --  slow  for  mouse  input  buffer 

Send_Cont  ro I ( Mouse_0a ta . C0M2_da ta , Mouse_0ata . mouse^f ormat ) ; 

Send_Control(Mouse_0ata.C0M2_modem_control,Mouse_0ata.sener8l_^int_enable); 

Send.Control (House_0ata.C0M2_int_enable,Mouse_0ata. specif {c_int_enable); 

Recei vo_Cont  ro I ( Mouse_0at a . pi c_8259_mr , I NTERRUPTS ) ; 

■■  enable  COM2  in  PIC  in  line  below 
INTERRUPTS  :*  Nouse_Oata.Bits_to_Byte 

(Mouse_Data.Syta_to_Bits( INTERRUPTS)  and  Nouse_0ata.pic_and_niask); 
Send_Cont  roll Mou8e_0a t a . pi c_8259_mr , I NTERRUPTS ) ; 
end  Initialize; 


task  body  Char_ln  is 

One  of  the  main  tasks  used  to  move  the  reticle  around  the  battlefield  screen. 
'•  The  task  rendezvous  with  the  graphics  task  reporting  positions  every  28 
••  millisaconds,  unless  the  middle  button  is  pressed  (mode)  changing  tha  moda 
'•  to  AUTOMATIC.  In  this  event,  the  mouse  sinply  waits  for  a  change  to 
••  MANUAL,  since  automstic  mode  is  controlled  by  the  rocket  task.  The  mouse 


--  for  input  of  8259  ints 
—  for  mouse  responses 

time  out  for  mouse  response 
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••  task  wflt  not  ranctezvous  uith  tha  graphics  task  mtil  sat  to  MANUAL.  Uhan 
in  MANUAL  node,  the  task  (upon  conpletion  of  one  xaport)  will  rendezvous 
*•  with  the  graphics  task  at  high  priority  to  report  it's  position.  It  will 
■*  then  change  the  status  task's  shared  variables  if  any  need  to  be  changed. 

-•  If  one  does,  and  the  status  task  has  conpleted  it's  previous  work  and  gone 
■*  to  an  accept  state,  then  the  mouse  task  wakes  it  up. 

use  Status;  ••  for  visibility  to 

use  Types;  —  for  visibility  to 

begin 

loop 

accept  Report  do 

Interrupt_Control.Clear_Oireetion_Flag;  -•  (RTE  bug) 

'•STP(00S6)  Mouse  task  start 

Receive_Control(MouseJ>ata.CaM2_status,0ATA);  ••  receive  status 
STATUS__BYTE  ;■  Mouse_0ata.8yte_to_Bit8(DATA);--check  statusbyte  for  errors 
if  STATUS_BYTE(Mou$e,Oata. overflow)  or 
STATUS^BYTE(MouseJ)ata. framing)  then 
REPORT_COUMT  :■  0;  --  Start  a  new  report 

Receive_Controt(Mouse_0ata.C0M2_dsta,DATA);  *•  clear  out  data  port 
else 

Receive_Control(Mouse_0ata.CtM2_data,0ATA);  ••  get  valid  data 
if  DATA  >  Mouse_Oata.sync_byte  then  ••  check  for  new  report 

REPORT_COUNT  :■  1;  --  start  of  new  report 

end  if; 
end  if; 

case  REPORT_,COUNT  is  ■*  convert  data  to  mouse  X,Y 

when  1  =>  ••  or  buttons. 

•»UTTON_PUSHEO  ;■  Mouse_0ata.8yte_to_8its(0ATA); 

REPORT_COUNT  :■  REP0RT_C0UNT  ♦  1; 
when  2  » 

MOUSE_lHPUT.LOU  :•  Mouse_0ata.8yte_to_Bit6<0ATA); 

REPORT_COUIiT  ;»  REPORT_COUNT  *  1; 
when  3  » 

MOUSE.INPUT.HIGH  :>  Mou8e_0ata.Byte_to_Bit6(0ATA}; 

MOUSE_REPORT  :■  Nou8e_0ota.Raw^to_Si8ned<M0USE_INPUT); 

TEMP_X  ;■  M0USE_REP0RT.L0W12; 

REPORT_COUNT  :■  REPORT^COUNT  ♦  1; 
when  4  ■> 

MOJSE.INPUT.LOW  :>  Mouse_0sts.Byte_to_Bit6(DATA); 

REP0RT_C0UNT  ;«  BEP0RT_C0UNT  ♦  1; 
when  S  » 

**  don't  move  mouse  if  any  buttons  pushed. 

if  (not  BUTTOH_PUSHED(Mouse_Osta. reset))  and  *-  guarantee  only  one  - 
(not  BUTTON_PUSHED(Mouse_Oata.mode))  and  *■  rendezvous  per  report- 
(not  BUTTON_PUSHED(Mouse_Data.lamch))  then  ••  (RTE  bug)  - 
PREV_BUTTON_PUSH(Mouse_Oata. reset)  :>  FALSE; 
PREV_BUTTON_PUSH(Mouse_Oata.made)  :■  FALSE; 
PREV.BUTTON_PUSH(Nouse_Oata. launch)  :■  FALSE; 

M(XiSE_INPUT.HlCM  :>  Mouse.Data.Byte_to_Bit6(0ATA); 
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MOUSE.REPORT  :>  Mouse.Data.Raw.to^SignedtNOUSE^INPUT); 

TEHP_Y  ;■  HOUSE_REPORT.LC3U12; 
ff  Status. NODE  ■  Status. MANUAL  than 
MOUSE_BUFFER.MOUSE_X  :«  TEMP_X; 

MOUSE_BUFFER.MOUSE_Y  ;■  TEMP_Y; 

-*STP<00S7)  Nousa  randazvous  with  Sava  start 
salact  ■■  Must  ba  conditional  to  work  in  INTERRUPT^HAHDLER 
Mousa_Buf f ar . Sava . Rat i c I a_Mot i on; 

-•STP(00S8)  Mousa  randazvous  with  Sava  and 
alsa 

raise  NOUSE.ERROR; 
end  select; 
end  if; 
else 

if  BUTT0N_PUSHED(Nouse_Dat8. reset)  and 

not  PREV_BUTTON_PUSH(Mouse_Oata. reset)  then 
for  1  in  Status. RESET_STATUS_TYPE  loop 
Status. STATUS_CONTROL(l). DATA  :«  0; 
'Status.STATUS_CONTROL<l). 01 SPLAYED  :■  FALSE; 
end  loop; 

Status. REQ.COUNT  :«  Status.REQ_COUNT  ♦  1; 

CHANGE.REOUESTED  :*  TRUE; 

PREV_BUTTON_PUSH<MousaJ)ata. reset)  ;«  TRUE; 
alsa 

if  not  8UTT0N_PUSHE0(Mousa_Dats.reset)  then 
PfiEV_8UTT0N_PUSH<Mou8e_0at8. reset)  :■  FALSE; 
end  if; 
end  if; 

if  BUTT0N_PUSHE0(Mouse_0ata.iaode)  and 

not  PREV_8UTT0N_PUSH(Mousa_Data.node)  then 
if  Status. NODE  «  Status. MANUAL  then 
Status. MODE  :«  Status.AUTOMATIC; 
else 

Status.MOOE  :«  Status. MANUAL; 
erd  if; 

Status. MOOE_D I  SPLAYED  :«  FALSE; 

Status.REO_COUNT  :«  Status. REQ_COUNT  *  1; 

CHANGE_REaUESTEO  :•  TRUE; 

PREV_8UTT0N_PUSH<Mouse_0ata.moda)  :>  TRUE; 
else 

if  not  BUTTON_PUSHEO(Mousa_Oata.Mada)  than 
PREV_BUTTON,PUSH(Mouse_Oata.tBoda)  :«  FALSE; 
end  if; 
end  if; 

if  BUTTON_PUSHED(Nouse_Oata. launch)  and 

not  PREV_8UTT0N_PUSH(Nousa_0ata. launch)  then 
if  Status.MOOE  >  Status.MANUAL  then 
Mouse^Buffer. LAUNCH  :•  TRUE; 

Nouse_Buffer.NEW_ABS_X  :«  Mause_Buffer.OLO_ABS_X; 
Mouse_8uffer.NEW_Aas_r  ;■  Mouoe_Buffer.OtO_ABS_y; 
end  if; 
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PREV  BUTTON _PUSH<Moo8«_Data.l«ifKh)  :«  TRUE; 

alta 

if  not  BUTTON_PUSHED(Mouae_Oata. launch)  then 
PREV  BUTT0N_PUSH(Hou8e_0ata.lauwh)  ;«  FALSE; 

end  if; 

•f>d  if* 

if  chamgE.REOUESTEO  and  then  Statue. REQ^OWHT  •  1  then 
-•$TP<0059>  house  rendezvous  with  Status  start 
select 

Status .Update. S i gna I ; 

••$TP(0060)  Mouse  rendezvous  with  Status  end 
else 

raise  MOUSE JRROR; 
end  select; 
end  if; 
end  if; 

CHAHCE_REOUESTED  ;»  FALSE; 

REPORT_COUMT  ;«  0; 
when  others  ■>  null; 
end  case; 

Send_Control(Mouse_0ata.pic_8259,Mouse_0ata.spec_eoi);  -  specific  Eol 

•>STP(0061)  Mouse  task  end 
end  Report; 
end  loop; 
exception 
when  others  *> 

Oebog_IO.Put_Line<"£rror  in  Char_In  Task"); 

Send_Cont rol (Mouse^Data .pi c_8259 , Mouse_0ata . spec_eoi ) ; 
raise; 

end  Chardin; 
end  House; 
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UNIT;  Nouse.Buffer  Package  Spec. 

•-|  Effects:  Buffers  mouse  data  input,  translates  it  to  pixel  system. 
*-|  Modifies:  No  global  data  is  modified  (other  than  in  oun  spec>. 

*>|  Requires:  No  initialization  is  required. 

'•|  Raises:  No  explicitly  raised  exceptions  are  propagated. 

•*1  Engineer:  M.  Sperry. 


--  Date  ;  10-24-88 

--  Purpose  : 

--  Package  Mouse.Buffer  contains  a  task  called  Save  which  is  responsible  for 
--  saving  reports  of  mouse  movement  via  a  rendezvous  with  an  interrtpt  task. 

--  The  task  then  rendezvous  with  the  display  task  to  relocate  the  reticle. 

with  Types; 
with  Config; 

¥ 

package  Nouse_Buffer  is 

stack_size  ;  constant  :■  118;  --  in  bytes 

M0USE_X  ;  Types. WORD;  --  for  use  with  the  Save  task  in  Mouse_Buffer 

MCXJSE_Y  ;  Types. WORD;  --  for  use  with  the  Save  task  in  Mous*_8uffer 

LAUNCH  :  BOOLEAN  :>  FALSE; 

0L0_ABS_X  :  Types. WORD;  --  absolute  X  position  of  Reticle  on  Screen 

0LD_ABS_Y  :  Types.UORO;  «  y  »  n  h 

NEU^ABS^X  :  Types.UORO;  --  for  use  by  ENGAGE  (latched  values  by  House  pkg) 
NEU^ABS^Y  :  Types.UORO; 

task  type  Save_Type  is 
entry  Reticle_Motion; 
pragma  PR!OR]TY(Conf ig.save_priority); 
end  Save_Type; 

for  Save_Type'STORAGE_SIZE  use  INTEGER(Config. bytes j5er_atorage_uni t  • 

stack_size); 

Save  :  Save.Type;  --  for  saving  motion  of  mouse  to  display 

end  Nouse_Buffer; 
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*1  UNIT:  Mouse_Buffer  Package  Body. 

*1  Effects:  Buffers  nouse  data  input,  translates  it  to  pixel  system. 
•|  Modifies:  No  global  data  is  modified  (other  than  in  own  spec). 

•|  Requires:  No  initialization  is  required. 

•|  Raises:  No  explicitly  raised  exceptions  are  propagated. 

-|  Engineer:  M.  Sperry. 


•-  Date  :  10-24-88 
--  Purpose  : 

Package  body  Nouse_Buffer  is  responsible  for  the  implementation  of  the 
■■  buffering  between  the  mouse  {nterns)t  routine  and  the  screen.  Note  that 
-•  checks  are  performed  to  be  sure  that  the  reticle  is  within  the  screen 
■-  defined  by  Config.  Also,  note  that  the  Y  coordinate  is  reversed  because 
■-  the  screen  on  the  EGA  rws  (in  the  Y  direction)  from  Q  to  349  starting 
**  from  the  upper  left  and  moving  down,  i.e.,  the  mouse  has  Y  direction  as 
*-  positive  movi/ig  up,  and  the  EGA  has  positive  moving  down. 


with  Shapes; 

with  Graphics; 

with  Config; 

with  Debug_IO; 

with  lnterrupt_Control; 

with  Time_Stamp; 

pragma  ELABORATE(0ebug_lO,  Graphics',  Interrupt^Control,  Time_Stamp); 
package  body  Mouse_Buffer  is 

use  Types;  —  needed  for  visibility  to 


task  body  Save_Type  is 


list_len  :  constant  :>  1; 


left_^limit 

right_limit 

top_limit 

bottom_limit 


constant  ;■  Config.battlef ield_screcn_left; 
constant  :■  Conf ig.battlef ield_scrcen_right; 
constant  :«  Config. battlefield_screen_top; 
constant  :>  Config. battlefield_screen_bottom; 


PRIORITY  :  Graphics. PRIORITY_TYPE  :■  Graphics. HIGH; 

II0RK_1.IST  :  Craphics.MOVE_LIST_TYPE(list_lon  .,  listjen);-  1  item  (reticle) 


TBMP_X  :  Types.MORD; 

TEMP_Y  :  Types. WORD; 


begin 


■*  Initial  display  of  reticle 
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UORK_LIST(list_len).XY_OLD  :»  (Config.battltf i«ld_center_x,  Confl9.b«ttlefield_center_y> 
UORIC_LIST(l{st_len).XT_NEW  ;■  (Conf {g.battlefield_cent«r_x.  Config.b«ttl»field_center^y) 
UORK.LISTdist.ltn) .OBJECT  :>  (Shapet.PIXEL.NOOE.Shapes.RETiaE); 

UORK_LlST(l{st_len). COLOB  :>  Graphics. r«ticle_color; 

Cr8phics.Display.Nove<PRI0RITT.  UORK.LIST); 

loop 

begin  ••  exception  block 

••STP(0062)  Mouse  Buffer  task  and  accept 
accept  Reticle_Notion; 

*-  Get  new  positions  of  reticle  (mouse) 

I nter rupt_Cont ro I . 0 i sabl e; 

TEMP_X  ;«  UORK_LlST(list_len).XY_OLO.X  ♦  M0USE_X; 

TEMP_Y  :«^K_LIST(lfst_len).XY_OLO.Y  -  M0USE_Y; 

Inter  njpt_Control .Enable; 

••  Check  bounds  of  reticle;  don't  let  it  go  past  edge  of  screen. 

if  (TEMP_X  ♦  Shapes.RETICLE_LEFT)  <  left.limit  then 
TEMPJt  :•  leftjimit  •  Shapes.RETlClE.lEFT; 
elsif  <TEMP_X  ♦  Shapes.RETICLE.RIGHT)  >  rightjimit  then 
TEMP_X:=  right_limit  -  Shapes.RETICLE.RIGHT; 
end  if; 

if  (TEMP_Y  ♦  Shapes. RET I CLE^TOP)  <  top_li*it  then 
TEMP_Y  ;■  top_limit  •  shapes. reticle_top; 
elsif  (TEMP^Y  ♦  Shapes. RETICLE.BOTTOM)  >  bottom_limit  then 
TEMP_Y  :»  bottom_limit  -  Shapes. RETICLE_BOTTOM; 
end  if; 

WORK_LIST(list_len).XY_MEU.X  :«  TEMP_X; 

WORK_LIST<list^len).XY_»(EU.Y  ;■  TEMP_Y; 


*•  update  global  accessable  values 

Interrupt_Control .Disable; 

0L0_ABS_X  ;•  TEMP_X; 

0L0_ABS_Y  :«  TEMP_Y; 

Interrupt_Control .Enable; 

••STP(0063)  Mouse_Buffer  rendezvous  with  Graphics  start 
Graphics.Oisplay.Move(PRIOBITY,  UORK.LIST); 

•■BTPlOOM)  Mouse_Buffer  rendezvous  with  Graphics  end 

WORr_LIST<list_len).XY_OLO  ;«  MORK_LIST{HstJen).XY_MEU; 
exception 
when  others  •> 
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0*bugJO.Put_Lin«<"Crror  in  S«v«"); 

and; 

— $TP<0065)  Noose_8uffer  task  and 
and  loop; 

and  Sava_Typa; 

end  Mouse_Butfer; 


•  axcaption  block 
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I  UNIT;  RDL  Package  Body  Subunit. 

I  Effects:  Supports  all  Rocket  Data  Link  functions  of  Simulator. 
I  Modifies:  No  global  data  is  modified. 

I  Requires:  No  initialization  is  required. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 

I  Engineer:  T.  Griest. 


••  The  RDL  package  provides  tasks  to  interface  to  the  Rocket  Data  Link 
-■  issuing  messages  for  new  rocket  positions  and  receiving  messages 
•-  cosmanding  new  rocket  attitudes. 

separate(Simulate) 

package  body  ROL  is  Rocket  Data  Link  Simulator 

stack_size  :  constant  348; 


task  type  Rock_Sup_Type  is 
pragma  PHIORITY<Config.rock_sup_priority); 
end  Rock_Sup_Type; 

for  Roek_Sup_Type'ST0RAC£_S12E  use  INTECERiConf ig.bytesj9er_storage_unit  * 

stack_size); 


Rock^Sup  :  Rock_Sup_Type; 


task  body  Rock_Sup_Type  is  separate; 


task  body  Report_Buf_Type  is  separate; 


task  body  Guide_Buf_Type  is  separate; 


end  RDL; 
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I  UNIT:  R«port_Buf  Task  Body  SUMnit. 

I  Effects:  Buffers  Rocket  report  data  between  simulator  and  Control. 
I  Modifies:  No  global  data  Is  modified. 

I  Requires:  No  Initialization  Is  required. 

(  Raises:  No  explicitly  raised  exceptions  are  propagated. 

I  Engineer;  T.  Griest. 


The  Report_Buf  task  acts  as  a  buffer  between  the  rocket  data  link 
support  task  Rock_Sup  and  the  Rocket. Contra I  task  which  processes 
the  rocket  data. 


TIMING  CONSIDERATIONS:  Report^Buf  will  only  provide  the  most  recent 
message  received.  If  two  messages  are  received  prior  to  one  being 
taken,  the  first  will  be  lost. 


with  Debu9_I0; 
with  Tiine_stamp; 

pragma  ELABORATElDebug.IO,  Time_Stanp); 


separate  (Simulate. ROD 


task  body  Report_Buf_Type  is 
use  Types; 

ROCKET_MSG  :  Rocket. ROCKET_MSG_TYPE; 
begin 

ROCKET_KSG.NUM_ROCKETS  0;  —  default 

loop 
select 

accept  Put_Report(0ATA  ;  in  Rocket. ROCKET_HSG_TYPE)  do 
•'$TP(0066)  Report_Buf  accept  Put_Report  start 
ROCKET_MSG.NUM_ROCKETS  :«  OATA.NUM_ROCKETS;  ••  copy  data 

for  I  in  Types.UORO.INOEX  range  1..0ATA.NUM_ROCKETS  loop 
ROCKET_MSG.ROCKET_UIST<I)  :■  OATA.ROCKET_LIST(I>; 
end  loop; 

--STP(0067)  Report_Buf  accept  Put_Report  end 
end  Put_Report; 
or 

accept  Get_Report(DATA  :  out  Rocket. ROCKET_MSG_TYPE)  do 
-■STP(0068)  Report_Buf  accept  Get_Report  start 
OATA.NUN.ROCXETS  :>  ROCJCET^NSG.NUM.ROCXETS; 
for  I  in  Types.UORO.INOEX  range  1..ROCKET_MSG.NUM,ROCKETS  loop 
DATA.ROCKET.LISTCI)  :»  ROCKET.HSG.ROCKET.LISTd); 
end  loop; 

•*STP(0069)  Report.Buf  accept  Get.Raport  end 
end  Get.Report; 
and  select; 
end  loop; 
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exception 

when  others  ■» 

OebugJO.Put_Lfne<"REPORT_BUF  tensination  <hie  to  exception.-); 
end  Repoft_3uf_Type,' 
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UNIT:  Rocket  Package  Spec. 

Effects:  Provides  structure  for  Rocket  manegment  within  SOS. 
Modifies:  No  global  data  is  modified. 

Requires:  No  initialUation  is  requi'*d. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


-•  The  Rocket  package  provides  all  processing  to  maintain  the  rockets 
-•  in  flight. 

with  Types; 
with  Config; 

peckage  Rocket  is 

stack.size  ^  :  constant  :*  1936;  --  in  bytes 


REPORT  INFORMATION 


type  ROCKET__lTEM_TYPE  is  record  provides  essentials  on  a  rocket 

TIME.TAO  :  Types.UORO; 

ROCICET_IO  :  Types. WORO_IMOEX; 

POSITION  :  Types. POSIT I ON.TTPE; 

end  record; 

type  ROCKET_lIST_TYPE  is  --|  list  of  all  rocket  data 

array<Types.WORO_INOEX  range  <»)  of  ROCJ(ET_ITEM_TYPE; 

type  R0CKET_MSGJYPE  is  record 

MUM_ROCKETS  ;  Types. W0RD_IN0EX; 

ROCKET^LIST  :  ROCICET_LIST_TYPE(1..Config.mBx^rocketS>; 

end  record; 


GUIDANCE  INFORMATION 


type  ROClCET_GUIOE_TYPE  is  record 
ROCKET.IO  :  Types.WQRO.INOEX; 

AIMPOINT  :  Types.AIMPOINT_TYPE; 

end  record; 

type  ROCKET_GUIDE_LIST_TYPE  is  -'I  list  of  all  guidance  data 
array(Types.WORO_INOEX  range  <>)  of  ROCKET_GUIOE_TYPE; 

type  ROCttT_GUIOE_MSO_TYPE  is  record 
NUM_ROCKETS  :  Types. WORD. INDEX; 
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R0CICET_GU1DE_LIST  :  ROCKET_GUIOE_LIST_TYPE(1  ..Conf i9.«*X_rockett>; 
•nd  record; 


task  type  Control_Type  ia  — |  for  overall  engagement  control 

entry  Get_Hext_lleport(ROCKET_REPOIlT_NSC  :  in  ROCICET_HSG_TYPE>; 
pragma  PRIORITYlConf ig.control_priority); 
end  Control_Type; 

for  Control_Type'STORAGE_SlZE  use  INTEGER(Config. bytea _per_storage_unit  * 

atack_s{ze>; 

Control  ;  Control_Type; 

end  Rocket;  package  specification 
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-•|  UNIT:  Rocket  Package  Body. 

Effect*:  Provides  structure  for  Rocket  managment  within  BOS. 
■*|  Modifies:  No  global  data  is  modified. 

-•|  Requires:  No  initialization  is  required. 

•-|  Raises:  No  explicitly  raised  exceptior^s  are  propagated. 

--|  Engineer:  T.  Griest. 


The  Rocket  package  provides  all  processing  to  maintain  the  rockets 
--  in  flight. 

with  Oebug_IO; 

with  Status;  maintair»  rxjiber  Rockets  Active 

with  Shapes;  -*  for  rocket  shapes 

with  Graphics;  -*  for  graphics  operations/colors 

with  Oistrib;  ^ 

pragma  ELABORATE(Defaug_IO,  Status,  Graphics); 
package  body  Rocket  is 

guidance_stack_size  :  coratant  :>  660; 


The  rocket  guidance  activity  is  given  overall  control  by  the  Control  task. 
-•  "Control"  is  used  to  accept  rocket  reports,  end  is  responsible  for  engaging 
**  the  targets,  providing  updates  to  the  Graphics. Display  task,  and  generating 
*•  the  guidance  messages  for  the  Rocket  Data  Link.  It  achieves  much  of  this 
••  with  the  assistance  of  one  (or  more)  Guidance  task(s).  The  Guidance  task 
■'  is  responsible  for  taking  a  set  of  the  rockets  and  producing  a  new 
aispoint  for  each  rocket/target  in  that  set.  The  activities  of  the 
*•  guidance  task(s),  as  well  as  the  Control  task  can  be  overlapped 
--  considerably,  and  therefore  may  benefit  from  the  addition  of  processors. 


GUIOANCE_LIST_ERROR  :  exception;  -*  if  guidance  list  does  not  match  history 

■■  This  history  data  is  provided  to  a  guidance  task,  which  in  turn  processes 
*>  it  and  returns  the  next  guidance  information  needed  for  each  rocket. 

type  HlST0RY_0ATA_TYPE  is  record  --I  containing  rocket  information 

ACTIVE  :  BOOLEAM;  --I  if  rocket  was  previously  active 

TARGET  :  Types. U0R0_IN0EX;  "|  rocket's  target 

POSITION_PAIR  ;  Types. POSIT I0N_PA I R_TYPE; 

end  record; 

type  HISTORY_LIST_TYPE  is 

arroy(Types.UORO_INOEX  range  <>)  of  NIST0RY_0ATA_TYPE; 
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tvoe  AIMPOIMT  LIST  TYPE  is 

•rrayCTypes.UQWJjNOEX  rsna®  <>)  of  Types. AIMPOIMTJYPE; 

ROCICET_HISTORY  :  HIST0RY_LIST_TYPE(1 .  .Conf ia.n«x_rockets); 

HEXT_GUIDE_HSG  :  ROCKET_GUIDE_MSG_TYPE; 

task  type  Guidance_Type  is 

entry  History(HISTORY_DATA  ;  in  H1ST0RY_LIST_TYP£); 
entry  Mext_Gui(tance(AlMPOINT_LIST  ;  out  AIMPOIMT_LIST_TYPE); 
pragma  PRIORITYCConf ig.guidance_priority); 
end  Guidance_Type; 

for  GuidanceJype'STORAGE.SIZE  use  INTECER(Config.bytesj)er_storage_iaiit 

guidance_stack_8i le) ; 

Rocket  Guide  :  arrayCTypes.WOROJMOEX  range  1,.0istrib.nua_guide_tasks) 

of  Guidance^Type; 


task  body  Cuidance_Type  is  separate; 
task  body  Control_Type  is  separate; 
end  Rocket;  *•  package  body 
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UNIT:  Rock_Sup  Task  Body  Subunit. 

Effects:  Provides  all  Rocket  Support  for  Simulator,  Including 
target  Intercept  detection. 

Modifies:  Updates  state  of  rockets  and  targets  in  Simulator  DBase. 
Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


ROCK_SUP  T  ask  Body 


--  The  rocket  support  task  provides  the  necessary  rocket  motion,  based 
--  on  previous  position  and  the  application  of  a  new  guidance  aimpoint. 

--  It  generates  s  new  report  “ROCKET_MS6"  for  a  buffer  task  (Report_Buf) 

--  to  forward  to  the  BOS  Rocket. Control  task.  Likewise,  the  Rocket. Control 
--  task  issues  guidance  messages  to  the  buffer  task  <Guide_8uf}  which  are 
--  made  available  to  the  Rock_Sup  task..  ROCKET/TARGET  intercepts  are 
*■  checked  in  the  shared  data  base  within  the  simulator.  In  such  eases, 
both  the  rocket  and  target  are  destroyed  (marked  inactive). 

-•  CopyrightlO  1988,  LabTek  Corporation.  Permission  is  granted  to  copy 
--  end/or  use  this  software  provided  that  this  copyright  notice  is  included 
-•  and  all  liability  for  its  use  is  acce'.ed  by  the  user. 

with  Traject;  -•  trajectory  planner 

with  Calendar; 

with  Interrupt_Control; 

with  Time_Stawp; 

pragma  ELABORATE (Traject,  Calendar,  tnterrupt_Control,  Time_Staiip); 
separate  (Simulate. ROL) 
task  body  Rock_Sup_Type  is 


use  Calendar; 

--  for  -  operator 

use  Types; 

--  for  operators 

start_position 

constant  Types. POSITION_TTPE  :» 

( Conf i g .  amt er s_ i n_ba 1 1 1 e_ 

ROCKET_MSG 

Rocket .  ROa(ET_MSG_TTPE ; 

GUIDE.MSG 

Rocket . ROCKET_GU I DE_NSC_T YPE ; 

GUIDE _MSC_INOEX 

Types. UORD.INDEX; 

REPORT_MSG_INDEX 

Types.W0R0_IN0EX; 

POSITION 

Types. POSJTION_TYPE;  —  temp 

TIME_TAC 

Types. WORD  :■  0; 

START_T1ME 

Calendar. TIME; 

DELAT.PERICO 

DURATION; 

"  NAKE_REPORT:  process  current  rocket  ID 
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procedure  Make_Report(IO  ;  Types. U0R0_IN0EX;  PCS  :  Types.POSlT10N_TYPE)  is 

checks  if  rocket  has  collided  with 
**|  any  targets  or  grotaid.  If  so,  delete 
*-|  target(s)  and  rocket. 

OELTA.X  :  Types.METERS; 

0ELTA_Y  ;  Types.METERS; 

DELTA_2  :  Types.METERS; 

DELTA_T  ;  Types. LONG^FIXEO;  —  time  for  rocket  to  reach  gro«xi 

ROCKET_POS  :  Types. POSITIOM_TYPE; 

begin  --of  Make_Report 

--STPIOOTO)  Rock_Sup.Make_Report  start 
if  POS.Z  <  0.0  then 

ROCXETSl ID). ACTIVE  FALSE;  —  destroy  rocket 

--  compute  time  it  took  to  get  to  zero 

DELTA.X  :e  POS.X  -  ROCKETS(IO). POSITION. X; 

DELTA_Y  ;■  POS.Y  -  ROCKETSCIO). POSITION. Y; 

DELTA_Z  :=  POS.Z  -  ROCKETSllO). POSITION. Z; 

if  0ELTA_Z  »  0.0  then 
0ELTA_T  ;«  0.0; 
else 

OELTAJ  !«  Types. LONG_FlXEO(ROCKETS(IO).POSlTION.Z/abs(OELTA_Z>); 
end  if; 

--  find  terminal  position  of  Rocket 

ROCKET_POS.X  ;»  ROCKETSllO). POSITION. X  ♦  Types.METERS{OELIA_T*OELTA_X); 
ROCKET_POS.Y  ;•  ROCKETSllO). POSITION. Y  ♦  Types. METERSlOELTA_T*OEUTA_Y); 
--TBO  since  targets  are  always  at  ZsO,  collision  point  is  always  0 

ROCKET_POS.Z  :»  ROCKETSllO). POSITION. Z  ♦  Types.METERSlOELTAJ*OELTA_Z); 

--  Now  search  target  list  to  see  if  any  targets  within  "kill.radius" 

--  perimeter  of  rocket 

for  TARGET_I0  in  TARGETS' range  loop 

Interrupt_Control. Disable;  --  access  to  shared  data 

if  TARGETSITARGET_ID). ACTIVE  then 
0ELTA_X  :«  ROCKET_POS.X  -  TARGETSlTARCET_IO).POSITION.X; 

0ELTA_Y  :«  ROCKET_POS.T  -  TARCETSITARGETJO).POSIT10N.Y; 

--rao  should  use  distance  DISTANCE  :>  Msth.Sprtl  Types.NETERS<DELTA_X*OELTA_X)  « 
--TBO  Types. M€TERS10ELTA_Y*0ELTA_T)  ♦ 

- - TBO  Types , METERSlDELTA_Z*OELTA_Z ) ) ); 

if  abs  0ELTA_X  <  Config.kill_radius  and  —  this  makes  square  box 
abs  0ELTA_Y  <  Config.kill_radius  —  around  each  target 
then 

TARCETSlTARGET_I0). ACTIVE  :•  FALSE;  —  destroy  target 
end  if; 
end  if; 
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1 nter rupt.Cont ro l . Enabl e; 
tnd  loop; 

•Im  '•  Rocket  dfd  not  hit  groind  or  target 

REPORT_MSG_INOEX  :«  REPO«T_MSG_lMOEX  ♦  1; 

ROCICET_MSG.HOC<ET_L1ST{REPORT_MSG_IMOEX)  :■  (TiME_TAG,ID,POS); 
end  if; 

-'$TP(0071)  Rock_Sup.Make_Report  end 
end  Nake_Report; 


ROCKET  SUPPORT  TASK  BOOT 


begin 

for  10  in  ROCKETS'range  loop 
ROCXETS(IO).ACTIVE  :>  FALSE; 
end  loop; 

START.TIME  :«  Calendar. CLOCK; 


initialize  to  all  inactive 


-*  find  out  when  xeq  begins 


'•STP(0072)  Rock_Sup  task  start 
START_T1ME  ;■  START_TIhE  ♦  Config. interval; 

if  TIHE_TAG  >  Types. UORO' last  then  ••  update  TtME^TAG  to  be  able 

T1ME_TAG  :>  0;  "to  differentiate  between 

else  --  stale  and  new  reports 

T1W_TAG  !«  TIh£_TAG  ♦  1; 
end  if; 

"STP(0073)  Rock.Sup  rendezvous  with  Guide.Buf  start 

R0L.Guide_Buf .Get_Guide<GUlDE_HSG);  -*  fetch  latest  guidance  message 

--$TP(0074)  Roek_Sup  rendezvous  with  Guide_Buf  end 

"  Go  through  each  rocket,  and  if  active,  apply  trajectory  to 
-•  current  position  for  1  interval. 

GUI0E_MSG_IN0EX  1;  •*  pointer  mBg.rocket_guide_list 

REPORT_HSG_INOEX  :«  0; 
for  ROCKET.ID  in  ROCKETS'range  loop 
if  GUIDE_MSG_tNOEX  GUIOE.HSG.NUM^ROCKETS  and  then 

ROCKET.IO  »  GU10E_MSC.ROCKET_GUIOE_L1STIGUIOE_NSG_1NOEX>.ROCRET_ID 
then 

This  rocket  is  in  the  list,  see  if  it  was  previously  active 

if  not  ROCKETS(ROCKETJD). ACTIVE  then 

••  filter  out  guidance  messages  for  rockets  that  have  recently  been 
"  destroyed  (but  BOS  doesn't  know  it  yet) 


if  GUIDE_NSG.ROCKET.GUIOE_LIST(GUIOE_MSG_IHOEX).AIMPOIHT. ELEVATION  «  16384 
then  "  a  new  launch 

ROCKETS(ROCKET_tO). ACTIVE  :■  TRUE;  "  lauKh 
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ROCKETS(ROCKET  JO). POSITION  :«  start  .position; 

Maka_Report(ROCICET  JO,  start  .position);  ••  start  at  lauwher 
and  if; 

also 

Now  compute  new  X,r,Z  position. 

POSITION  :»  Trajeet(  ROCKETS(ROCttT JO). POSITION, 

GUIOE.NSG.ROCKET_GUIOEJIST(GUIOE_MSG_INOEX).AINPOIMT); 
Nake.Repor  t  (  ROCKET  JO ,  POS I T I  ON  )  ; 

ROCKETS(ROCKET JO). POSITION  :«  POSITION; 
end  if;  ••  rocket  active  check 
GUIOE.HSGJHOEX  :>  GUIOE.NSGJNOEX  *■  1; 
else  —  no  guidance  for  this  rocket 

if  ROCKETS(ROCKET_IO). ACTIVE  then 

■■  no  guidance  information  for  active  rocket,  simply  don't  move  it 

POSITION  :>  ROCKETSIROCKET JO). POSITION; 

Make_Report(ROCKET  JO , POSITION); 
end  if;  ••  rocket  active  check 

end  if;  *•  guide  entry  exists  check 

end  loop; 

••  New  report  list  has  been  generated.  Send  it  to  buffer  task. 

ROCKET.HSG.NUN.ROCKETS  ;»  kEPORT.NSG_INOEX; 

-•$TP(0075)  Rockjup  rendezvous  with  Report.Buf  start 
ROL.Report.Buf .Puc.ReportlROCKET.NSG);  ••  issue  next  rocket  report 
--$TP<0076)  Rock.Sup  rendezvous  with  Report.Buf  end 

■*  Delay  to  make  rocket  motion  reports  periodic 

DELAY.PERIOO  :»  STARTJIHE  •  Calendar.CLOCK; 
if  DELAY.PERIOO  <  0.0  then 
STARTJINE  ;»  CLOCK; 
end  if; 

■•STP(0077)  Rock.Sup  task  end 
delay  OELAY.PERIOO; 
end  loop; 

end  Rock.SupJype; 
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UNIT:  Shapes  Package  Spec. 

Effects:  Provides  all  graphics  synSMlogy. 

Modifies:  No  global  data  is  nodified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propageted. 

Engineer:  T.  Griest  /  M.  Sperry. 


SHAPES  PACKAGE  SPECIFICATION 


••  Date  :  10-12-88 
--  Purpose  : 

Package  Shapes  is  responsible  for  determining  the  shapes  of  the  various 
--  syinbols. 

with  Types; 
with  Config; 

package  Shapes  is 

type  SYMBOC.TTPE  is  (ROCKET,  TARGET,  RETICLE,  DOT,  ZERO,  ONE,  TWO,  THREE,  FOUR, 
FIVE,  SIX,  SEVEN,  EIGHT,  NINE,  HORIZONTAL,  VERTICAL); 

type  0BJECT_M00E_TYPE  is  (TEXT_M00E,  PIXEL_MOOE); 

type  PIXEL  is  record 

X: Types. COORD I NATE  range  Conf ig.enti re_8creen_left.. Config. entire_screen_right; 
Y;Types. COORDINATE  range  Config.entire_screen_top.. Config. entire_screen_bottom; 
end  record; 

type  REL_PIXEL  is  record  --  offset  froai  base  of  pixel 

X_OFFSET  :  Types. REL.COORD I NATE;  --  positive  goes  right 

Y.OFFSET  :  Types. REL.COORD I NATE;  -*  positive  goes  down 

end  record; 

type  PIXEL_LIST  is  array( Types. UORD_INOEX  range  o)  of  REL.PIXEL; 

type  OBJECT_TYPE<OBJECT_MOOE  :  OBJECT_MOOE_TYPE  :■  TEXT_M0DE)  is  record 
case  0BJECT_M00E  is 
when  TEXT^NOOE  » 

TEXT.QBJECT  :  STRINGd . .Config. stats_title_max_length); 
when  PIXEL.NOOE  ■> 

PIXEL.OeJECT  :  SYMBOL_TYPE; 

end  case; 

end  record; 

type  OSJECT.PTR  is  access  PIXEL.LIST; 
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reticle_left 

:  constant  :»  -5; 

—  constants  used  to  check  if 

reticle_right 

:  constant  :■  5; 

—  reticle  going  past  screen 

reticle.top 

:  constant  :>  -5; 

--  boundaries. 

reticle  botton 

:  constant  :»  5; 

**  Th«  following  two  constants  detemlna  how  far  the  target  center  can 
•-  be  in  meters  from  the  indicated  reticle  center  and  still  allow 
aquisition  of  the  target  for  launching  a  rocket.  They  are  not  the 
■■  sane  in  X  and  X,  since  the  reticle  is  slightly  rectangular. 

reticle_x_error;  constant  ;»  40.25;  ••  METERS  to  allow  target  aquisition 

l■eticle_y_error;  constant  ;■  49.50;  •-  METERS  to  allow  target  aquisition 

RUMERIC  :  array(0..9)  of  SYMBOL^TYPE  :*  (ZERO,  ONE,  TWO,  THREE,  FOUR, 

FIVE,  SIX,  SEVEN,  EIGHT,  NINE); 

rM«ber_width  ;  constant  ;«  8;  --  widest  nuitoer  in  pixels 

0BJECT_PTR_TABLE'  ;  array(SYMBOL_TYPE)  of  OBJECT_PTR  :« 

(TARGET  ■>  new  PIXEL_LIST'( 

<0,>2), 

(l.'D, 

(-2,0),  (0,0),  (2,0), 

(1,1), 

<0,2)  ), 


ROCKET  «>  new  PIXEL,LIST'( 

<0,0), 

<0,1), 

<0.2). 

(0,3), 

(-1.4),  (1,4)  ), 


RETICLE  *>  new  PIXEL_LIST'( 

(-5. -5), (-4, -5). (-3, -5), 

(-5.-4). 

(-5,-3),  (0,-3), 

(0.-2). 

(0,-1). 

(-3,0),  (-2,0),  (-1,0),  (0,0),  (1,0), 

(0,1). 

(0.2), 

(-5,3),  (0,3), 

(-5.4), 

(-5, 5), (-4, 5), (-3, 5), 


(3, -5), (4,-5), (5, -5), 
(5,-4), 
(5,-3). 


(2.0),  (3,0), 


(5.3) , 

(5.4) . 

(3,5), (4,5), (5. 5)), 


DOT  ■>  new  PIXEL_LIST'(  (0,0), (0,0)  ), 


ZERO  ■>  new  PIXEL_LIST'(  (1,-8),(2,-8),(3,-8),(4.-8),(5,-B). 

(6.-7). 
(5,-6), (6, -6). 
(4.-5).  (6,-5). 


(0,-7) 

(0,-6) 

(0,-5) 
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(0,-4),  <3^:4), 

(0,-3),  <2,-3), 

<0,-2),<1,-2). 

(0.-1), 

(1,0>,  (2,0),  (3,0),  <4,0),  (5,0» 


(6,-4), 
<6, *3), 
(6,-2), 
(6,-1). 


ONE  »>  ne«  PIXEU_LIST'<  (4,-8), 

(3, -7), (4,-7), 

(4,-6), 

(4,-5), 

(4, -4), 

(4,-3), 

(4.-2). 

(4,-1), 

(3.0),  (4,0),  (5,0)), 

TVn  »»  new  PIXEL_L1ST'(  (1,-8), (2, -8), (3, -8), (4, -8), 

(0,-7),  (5,-7). 

(5. -ft). 

(4,-5). 

(3,-4), 

(2.-3). 

(1.-2). 

(0.-1). 

(0.0).  <1.0),  (2,0).  (3.0),  (4,0),  (5,0)), 

THREE  «>  new  PIXEL_tlST'(  (1,-8), (2, -8), (3, -8), 

(0,-7).  (4,-7), 

(4,-6), 

(4,-5). 

(2. -4), (3. -4), 

(4.-3), 

(4,-2), 

(0,-1),  (4,-1), 

(1.0).  (2,0),  (3,0)), 


FOUR  «>  new  PIXEL_LIST'( 


(4,-8), 

(3. -7), (4, -7), 

(2,-6),  (4,-6). 

(1,-5),  (4,-5), 

(0,-4), (1,-4), (2, -4), (3, -4), (4, -4), (5, -4), 

(4,-3), 

(4,-2), 

(4,-1). 

(3,0),  (4,0),  (5,0)), 


FIVE  ■>  new  PIXEL_LIST'( 

(0,-7). 

(0,-6), 

(0.-5), 


(1,-8),(2,-8),(3,-8),(4,-8),(5,-8), 


(1,-4), (2,-4), (3,-4>,(4,-4), 
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(0,0). 

SIX  »>  new  PIXEL_LIST'( 


(0.-6), 

(O.-S), 

(0.-4), 

(0.-3), 

(0.-2), 

(0.-1). 


(5,-3) 

(5,-2) 

(5,-1) 

(1,0),  (2,0),  (3,0),  (4,0),  (5,0)) 
(3,-8),(4,-8), 

(2,-7), 

(1,-7), 

(1,-5), (2,-5), (3,-5), 

(4.-4), 

(4.-3). 

(4.-2). 

(4,-1). 

(1.0),  (2.0),  (3.0)), 


SEVEN  »>  new  PIXEL  LIST'(  (1,-8), (2, -8), (3, -8), (4,-8), (5, -8), 

(0.-7).  (5.-7), 

(4.-6). 

(3,-5). 

(2,-4), 

(1,-3), 

(0,-2), 

(0,-1). 

(0,0)), 


EIGHT  s>  n«}w  PIXEL_LIST'( 

(0,-7), 

(0,-6), 

(0,-5), 

(0,-3), 

(0,-2), 

(0,-1), 


(1,-8), (2,-8), (3,-8), (4,-8), 

(5,-7), 

(5,-6), 

(5,-5), 

(1,-4), (2, -4). (3,-4), (4, -4), 

(5,-3), 

(5,-2). 

(5,-1), 

(1,0),  (2,0),  (3,0),  (4,0)), 


NINE  «>  new  PIXEL_LIST'(  (1, -8), (2,-8), (3,-8), (4,-8), 

(0,-7),  (5,-7), 

(0,-6),  (5, -6), 

(0.-5),  (5, -5), 

(1,-4), (2, -4), (3,-4), (4,-4), (5, -4), 

(5,-3), 

(4,-2), 

(3,-1), 

(1,0),  (2,0)), 

HORIZONTAL  •>  new  PIXEL_LIST'(<0,  0),(1,  0),(2,  0),(3,  0),(4,  0),(5,  0), 

(6,  0),(7,  0),(8,  0),(9,  0), (10,0), (11,0), 
(12,0), (13,0), (14,0), (15,0), (16,0). (17,0), 
(18,0), (19,0), (20,0), (21,0), (22,0), (23,0), 
<24. 0). (25,0), (26,0), (27.0). (28,0), (29,0). 
(30,0), (31,0), (32.0), (33,0), (34,0), (35,0), 
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(36.0). (37,0), (Sa.OX,  <39,0), <40,0). <41,0), 
(42,0), (43,0), (44,0), <45,0),<46,0), (47.0), 
<48,0), (49.0), (50,0), (51,0), <52,0),<53,0), 
(54.0), (55,0), (56,0), <57,0),<5a,0),<59,0). 
(60,0), <61 . 0). (62,0), (63,0). (64,0), (65,0) , 
(66,0), (67,0), (68.0). <69.0),<70.0), (71,0), 
(72,0), (73,0), (74,0), (75,0), (76,0), (77.0), 
(78.0)), 

VERTICAL  ■>  new  PIXEL_HST»<<0,  0),<0,  1),<0,  2),<0,  3),<0,  4),<0,  5), 

<0,  6),<0,  7),<0.  8),<0,  9), (0,10). (0,11), 
<0, 12), (0,13), (0.14), (0,15))); 

end  Shapes; 
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UNIT:  SensQr  Package  Body  Subunit. 

Effects:  Provides  structure  for  all  simulator  Target  motion. 
Modifies:  Simulator  target  data  is  updated. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


--  Simulator  package  to  provide  testing  of  BOS  system 
separate(Simulate) 

package  body  Sensor  is  --|  Target  Sensor  Simulator 

task  body  Targ_Sup_Type  is  separate; 
end  Sensor;  --  body 
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UNIT:  Simulate  Package  Spec. 

Effects:  Provides  shared  data  base  for  simulator. 

Modifies:  No  global  data  is  modified. 

Requires:  Individual  tasks  are  responsible  for  init.  of  global  data. 
Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


-■  Simulator  package  to  provide  testing  of  BOS  system 

with  Target; 
with  Rocket; 
with  Sync; 
with  Config; 

package  Simulate  is  •-(  Overall  simulation  package 

package  Sensor  is  Target  Sensor  Simulator 

stack^size  :  constant  ;■  114;  •*  in  bytes 

task  type  Targ_Sup_Type  is 
pragma  PR I OR I T Y  <  Conf i g . t ar g_sup jsr i or i ty ) ; 
entry  Mext_Target_Mag(Oata  :  out  Target. TARGET_MS6_TYPE); 
entry  Clock(Time  :  in  Sync.TIME_TYPE); 
end  Targ_Sup_Type; 

for  Targ_Sup_Type'ST0RAGE_SI2E  use  INTEGERlConf ig.byte8_per_storage_unit  * 

stack_size); 

Targ_Sup  :  Targ_Sup_Type; 
end  Sensor; 

package  ROL  is  --|  Rocket  Data  Link  Simulator 

report_buf_stack_size  :  constant  ;«  302;  --  in  bytes 

guide_buf_stack_size  :  constant  :«  744;  ••  in  bytes 


-•  The  Report_Buf  task  buffers  Rocket  Reports  from  the  Rock_Sup  task 
and  provides  them  to  the  Rocket. Control  task 

task  type  Report_Buf_Type  is 
pragma  PRIORlTYlConf ig.report.buf _priority); 
entry  Put_Report(0ATA  :  in  Rocket. ROCKET_MSG_TYPE); 
entry  Get_Report(0ATA  ;  out  Rocket. ROCKET_MSG_TYPE); 
end  Report_Buf_Type; 

for  Report_Buf_Type'STORAGE_SlZE  use  IMTEGER(Config.bytes_per_storoge_unit 

•  report_buf_stack_size); 

Report_Buf  :  Report_Buf_Type; 
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••  Th«  Guide_Suf  task  buffers  new  Guidance  messages  froai  the  Rocket. Centro I 
-•  task  for  delivery  to  the  Rock_Sup  task. 

task  type  Guide_Buf_Type  is 
pragma  PRIORITY(Config.guide_bufjpriority); 
entry  Put_Guide<DATA  ;  in  Rocket.ROCICET_GUlDE_MSG_TYi>€); 
entry  Get_Guide(DATA  ;  out  Rocket. ROCKET_GUIOE_i«G_TYPE); 
end  Guide_Buf_Type; 

for  Guidc_Buf^Type'ST0RAGE_SI2E  use  lNTEGER(Config.faytes_per_storage_unit 

•  guide_buf_stack_size); 

Guide_auf  :  Guide_Buf_Type; 
end  RDL; 
end  Simulate; 
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I  UNIT:  Sinulat«  Package  Body. 

I  Effects:  Provides  shared  data  t>ase  for  Simulator. 

(  Modifies:  No  global  data  is  modified. 

I  Requires:  Individual  tasks  are  responsible  for  init.  of  global  data. 
I  Raises:  No  explicitly  raised  exceptions  are  propagated. 

I  Engineer:  T.  Griest. 


with  Types; 


-•  Simulator  package  to  provide  testing  of  BOS  system 

package  body  Simulate  is  --|  Overall  cimulation  package 


-•  TARGET  DATA 


type  TARG£T_SIM_TYPE  is  record  --|  provides  individual  target  information 
ACTIVE  :  BOOLEAN; 

POSITION  :  Types.POSITION^TYPE; 

TARGET_CLASS  :  Types. TARGET_CLASS_TYPE; 

end  record; 

type  TARGETS_TYPE  is 

array<Types.«ORO_IMOEX  range  1..Config.mox_torgets)  of  TARGET_SIN_TYPE; 
TARGETS  ;  TARGETS^TYPE; 


—  ROCKET  DATA 


type  ROCKET_SIM_TYPE  is  record  --I  provides  individual  rocket  information 
ACTIVE  :  BOOLEAN; 

POSITION  :  Types. POSITION_TYPE; 

end  record; 

type  ROCKETS_TYPE  is 

array(Types.UORD_IMDEX  range  1..Config.max_rockets)  of  ROCKET_SIM_TYPE; 
ROCKETS  :  ROCKETS_TYPE; 

package  body  Sensor  is  separate;  -*|  Target  Sensor  Simulator 

package  body  RDL  is  separate;  *-|  Rocket  Oats  Link  Simulator 

end  Simulate;  *■  body 
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UNIT:  Status  Package  Spec. 

Effects:  Maintains  indicators  and  statistics  on  graphics  display. 
Modifies:  Flags  are  cleared  in  spec,  when  values  are  displayed. 
Requires:  Initialization  must  be  signaled  by  main  for  first  display. 
Raises:  Mo  explicitly  raised  exceptions  are  propagated. 

Engineer:  M.  Sperry. 


--  Date  :  11-08-88 
--  Purpose  : 

--  The  purpose  of  the  Status  specification  package  is  to  provide  visibility 
-■to  the  data  base  which  holds  the  requests  from  the  mouse,  et.  al.  The 
--  requests  are  entered  into  a  data  table  (called  STATUS_CONTROL}  and  then 
--  the  table  is  checked  to  see  if  any  updating  of  the  statistics  needs  to  be 
--  done.  The  checking  of  the  table  is  done  at  an  atomic  level  to  prevent 
--  the  shared  data  from  being  corrupted  at  critical  times.  The  commands  are 
-•  processed  from  the  mouse  interrupt  as  mode  first,  then  reset  if  there  are 
--  two  conmands  to  perform. 

with  Types; 
with  Config; 

package  Status  is 

stack_size  :  constant  :*  252; 

type  M00E_TYPE  is  (AUTOMATIC, MANUAL); 

type  STATUS_TYPE  is  (AIRBORNE,  TRACKED,  EXPENDED,  DESTROYED); 
subtype  RESET_STATUS_TYPE  is  STATUS_TYPE  range  EXPENDED. .DESTROYED; 
type  STATUS_RECORD  is  record 

DATA  :  Types. WORD  :•  0;  -*  new  statistic 

DISPLAYED  :  BOOLEAN  :>  FALSE;  -  need  to  display 

end  record; 


type  STATUS_TYPE_ARRAY  is  array(STATUSJYPE' FIRST  ..  STATUS_TYPE'LAST)  of 

STATUS_RECORD; 


--  define  shared  variables 


MODE 

MOOE.D  I  SPLAYED 
STATUS_CONTROL 
REO.COUNT 


:  M00E_TYPE  :»  MANUAL; 
:  BOOLEAN  :«  FALSE; 

;  STATUS_TYPE_ARRAr; 

:  Types. WORD  :*  0; 
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STATUS.ERROR  :  EXCEPTION;  -  ctata  n«9*t«ve 

define  subprograns  and  taaka 

procedure  Initialize;  **  initialization  of  aereen 

task  type  Update.Type  is 
entry  Signal; 

pragma  PRIORITYtConf ig.update_priority); 
end  Update_Type; 

for  Update_Type'ST0RAGE_SI2E  use  INTECERlConf ig.bytes_per_atorage_irit  • 

stack.size); 

Update  :  Update_Type; 

end  Status; 
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t  UNIT:  Status  Package  Body. 

I  Effects:  Maintains  indicators  and  statistics  on  graphics  display. 
I  Modifies:  Flags  are  cleanad  in  spec,  uhen  velucs  are  displayed. 

I  Requires:  Initialization  must  be  signaled  for  first  display. 

I  Raises:  No  explicitly  raised  exceptions  are  propegated. 

I  Engineer:  M.  Sperry. 


-•  Date  ;  11*08-88 
•*  Purpose  : 

The  purpose  of  the  status  package  body  is  the  implementation  of  the  status 
--  update  task.  Although  operating  at  a  low  priority,  the  update  task  updates 
•*  the  various  statistics  by  a  rendezvous  with  the  graphics  task. 

with  Graphics; 

with  lnterrupt_C6ntrol; 

with  Shapes; 

with  Machine_Oependent; 

with  Interrupt_Control; 

with  Debug_I0; 

with  Time_Stamp; 

pragma  ELABORATE (Graphics,  Interrupt_Control,  Debug_10,  Time^Stamp); 
package  body  Status  is 

use  Types;  -•  for  visibility  to 

procet^re  Initialize  is 

--  A  procedure  which  initializes  the  screar,  for  the  various  statistics 
--  descriptions.  It  also  signals  the  status  update  task. 


T1TLE_PRI0RITY  :  Graphics. PRIORITY_TYPE  ;»  Graphics. LOU; 


•  TITLES  :  Graphics.MOVE_LIST_TYPE<1..12)  :» 

((( 0 , 0 ),( 0 , 0 ),< Shapes . TEXT_M00E , "A i r borne 
((0,0),<0,1), (Shapes. TEXT_MOOE,"  Rockets: 
(( 0 , 0 ),( 0 , 3 ),( Shapes . TEXT_M00E , "T racked 
((0,0),<0,4),(Shape8.TEXT_M0OE,"  Targets: 
((0, 0>,(0, 8), (Sh apes. TEXT_M00E, "Totals 
(( 0 . 0 },( 0 , 1 0) , (Shapes . TEXT_M00E , "Expended 
((0,0).(0,11),( Shepes . TEXT_NOOE , "  Rockets : 
((0,0) , (0, 13) , (Shapes. TEXT_MOOE, "Destroyed 
((0,0), (0.14), (Shapes. TEXT_M0OE,"  Targets: 
( ( 0 , 0 ) , ( 0 , 1 8 ) , ( Sh apes . T EXT_M00E , "Mode ; 

((0, 0), (0,20), (Shapes. TEXT_MG0E,"  Manual 
( ( 0 , 0 ) . ( 0 , 22) , ( Shapes . TEXT_MOOE ."Automatic 


" ) , Graph i cs . s ta tus_co I or ) , 
"), Graph i cs . status_col or ) , 
"), Graphics. status_color), 

"  ) ,  Graph  i  cs .  St  atus_col  or ) , 

" ) ,  Graph  i  cs.  status_co  I  or ) , 
"), Graphics. status_color), 
"),Graphics.status_color), 

, Graph ics. status.col or ) . 
"), Graphics. status_color), 
"),Graphics.status_color), 

" ) , Gr aph i cs . s ta tus_co I or ) , 
"), Graph i cs . status_col or )) ; 


begin 

Graph ics .0 ispl ay.Move( T I TLE.RR lOR I TY , T I TLES ) ; 
Interrupt_Control.Dissble;  go  atoaiic 
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Status. REQ_COUNT  :■  Status. REO.COJNT  1;  ••  signal  a  raquast  (print  zeroes) 

Internpt_Control  .Enable; 

Status. Update. Signal;  --  display  statistics  values 

end  Initialize; 

task  body  Update_Type  is 

use  Types;  —  for  visibility  to 

x_start  :  constant  :>  11;  **  colunn  that  ststus.box  starts  in  x 

x_end  :  constant  :«  90;  ••  end  colum  of  status.box 

y_top_start_A  :  constant  :■  307;  --  status^box  top  AUTOMATIC 

y_bottom_start_A  :  constant  :■  322;  --  statusjbox  bottom  AUTOMATIC 

y_top_start_M  :  constant  ;■  278;  -*  atatus^bex  top  MANUAL 

y_bottom_start_M  :  constant  :>  293;  --  statusjMX  bottom  MANUAL 

■anual^offset  ;  constant  :»  29;  --  offset  to  draw  8tatus_box 

box_start  :  constant  :>  1;  ••  range  of  components  that 

box_end  :  constant  :■  4;  make  up  status.box. 

base_x  :  constant  Types. COORD  I  NATE  120;**  x  end  of  all  statistics 

airborne_y  ,  :  constant  Types. COORDINATE  :«  25;  —  y  location  of  stat 
tracked_y  :  constant  Types. COORD I NATE  :■  67;  --  y  location  of  stat 

expended.y  :  constant  Types. COORD I NATE  :*  165;  **  y  location  of  stat 

destroyed_y  :  constant  Types. COORD I NATE  :«  207;  ••  y  location  of  stat 

y_statistica  ;  constant  array<STATUS_TYPE' first  ..  STATUS_TYPB'last>  of 
Types. COORDINATE  ;■  <airborne_y,  tr8cked_y,  expended_y,  destroyed^y); 

type  STATUS_OLO  is  array<STATUS_TYPE' first  ..  STATUS.TYPE'lest, 

1  ..  Config.statisties_length)  of  Graph ics.MOVE^RECORD; 

NEXT_M0DE  :  M0DE_TYPE; 

D1SPLAY_REQUIRED  :  BOOLEAN; 

NEXT.DATA  :  Types.UORD; 

B0X_L1ST  :  Graphics.MOVE_LIST_TYPE<Types.WOROJ»»EX  range  box_start. .box^end); 

DATA^OLD  ;  STATUS_0L0; 

W0RK_L1ST  ;  Gr8phics.M0VE_LIST_TYPE{1  ..  Config.statisticsjength); 

MOVE_PRIORITY  :  Graphica.PRIORITY_TYPE  ;■  Graphics. LOW; 


procedure  Initialize  is 

••  A  procedure  which  intializes  the  OATA_OLO  data  base.  This  procedure  does 
••  NOT  cause  the  digits  to  be  drawn.  Then,  it  initializes  the  status.box  around 
'manual'.  Again,  it  does  not  cause  the  status_box  to  be  drewn.  A  wakeup 
••  from  the  main  task  will  cause  it  to  be  drawn. 

begin 

for  1  in  ST ATUS.TYPE' first  ..  STATUS_TYPE'last  loop 
for  J  in  1  ..  Config.statistics_length  loop 
DATA_OLD(I,J).XY_OLD  :■  (Types.COOROlNATE<base_x),Types.COOR01NATE(y_8tati8tics(I)>); 
DATA_OLD(I,J).XY_NEW  :»  (Types.C00R0INATE(ba8e_x),Types.C00RDINATE(y_stati8tic8<I))); 
DATA_01D(I,J).0BJECT  :■  (Shapes. PIXEL_M00E,Shapes.ZER0); 
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OATA_OLO(I,J). COLOR  :«  Graphics. statiis_color; 
end  loop; 
end  loop; 

••  Now  initialize  top  of  status_box 
BOX_LIST(1),XY_OLO  :» 

(Types.COOROINATE(*_start),Types.COO«DIMATE(y_top_start_A)); 
BOX_LIST(1).XY_MEU  :« 

(Types .  COORO I  NATE(x_start ) ,  Types  .COORD  INATE(y_top_start_A»  ; 
BOX_LIST(1).0BJECT  :>  (Shapes.PIXEL_MOOE,Shapes.HORIZONTAL); 
BOX_LIST(1),COLOR  :«  Graphics. status_box_eolor; 

••  define  bottom  of  status^box 

BOX_L1ST(2).XY_OLO  :■ 

(Types. COOROINATE(x_start),  Typea.COOROINATE(y_bottom_start_A>>; 
B0X_L1ST(2),X^_MEU  :■ 

(Types. C0OR01NATE(x_Start).  Types. COORO tNATE(y_bottam_start_A)); 
B0X_L1ST(2). OBJECT  :«  ( Shapes. P I XEL.MODE, Shapes. HORIZONTAL); 
BOX_LIST(2).COLOR  :>  Graphics. status_box_color; 

--  define  left  side  of  statua_box 

8OX_LIST(3).XY_OL0  :« 

•  (Types. COORDINATE(x_start),  Types. COORDIHATE(y_top_start_A>>; 

BOX_LIST(3).XY_HEU  :» 

( Types . COORO I HATE ( x_st art ) ,  Types . COORO I HATE(y_top_stsr t_A ) ) ; 
BOX_LIST(3). OBJECT  :»  (Shapes. PIXEL.NOOE, Shapes. VERTICAL); 

BOX_LIST{3).COLOR  :■  Graphics. statU3_box_color; 

--  define  right  side  of  status_box 

B0X_LlST(4).xy_0LD  :» 

(  T ypes .  COORD  I  NATE  ( x_end) ,  Types .  CCXIRD I  NATE(y_top_start_A  ) ) ; 
80X_LIST(4).XY_HEW  ;« 

(Types. COORD INATE(x_end),  Types.COOROINATE(y_top_start_A)); 
BOX_LIST(4).OPJECT  :■  (Shapes.PIXEL_NOOE,Shapes.VERTICAL); 

BOX_LIST(4).COLOR  :*  Graphics. status_box_color; 
exception 

when  others  *>  Oebog_IO.Put_Line("Exception  raised  in  Status. Initialize'*); 
end  Initialize; 


procedure  Update_Box(NEXT_MQOE  ;  MOOE_TYPE)  is 

A  procedure  which  updates  the  four  objects  which  represent  the  status_box 
"  surroteiding  one  of  the  modes. 

OFFSET  :  Types. WORD; 
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begin 

-•STP(0078)  Status. Update.Box  start 

if  NEXT.moE  >  AUTOMATIC  then  —  draw  status.box  at  'autosMtie' 

B0)(_L1ST<1).XT_MEW.Y  :■  Types. COOW)lMATE(y_top_start_A); 

B0K_L1ST(2).XY_MEU.Y  :•  Types. COQROINATETy.bottoai.startJO; 

B0X_LIST<3>.XY_HEU.Y  :■  Types. COOROIMATE<y_top_start_A); 

B0X_t.ISTC4).XT_MEW.Y  :«  Types. COO«)INATE(y_top_start_A); 
else  *■  draw  status.box  at  'aanual' 

B0X_LIST{1).XY_MEU.Y  :«  Types. COOW)lHATE<y_top_atartJI  ); 

B0X_L1ST(2).XT_MEU.Y  :«  Types.COORDIMATE(y_bottoa(_startJO; 

B0X_LIST{3).XY_XEU.Y  ;■  Types. COO*OIMATE(y_top_startJI); 

B0X_LIST(4).XY_MEU.Y  ;»  Types. COORDIIlATE(y_top_start_M); 
end  if; 

-*  Rendezvous  with  Graphics  to  draw  new  status_box 
>*STP(0079)  Status. Update_Box  rendezvous  with  Graphics  start 

Graphics.0isplay.Nove(M0VE_PR10RITY,  BOX_LlST(Types.UORDJNDEX  range  box_start. .box_end)>; 
--STP(0080)  Status. Update  Box  rendezvous  with  Graphics  end 

••  Update  status_box  lists 

for  (  in  Types.MORO.ItlOEX  range  boxjttart  ..  box^end  loop 
BOX_LIST<I).XY_OLO  ;■  BOX_LIST<I).XY_MEW; 
end  loop; 

-•STPIOOSI)  Status. Update_Box  end 
end  Update^Box; 


procedure  Oisplay_Oigits(MEXT_OATA  :  in  out  Types. UORD; 

STAT  :  STATUS.TYPE)  is 

--  A  procedure  which  takes  the  OATA_OLO  nunbers,  divides  by  10  to  get  a  single 
-•  digit.  That  digit  is  used  as  an  index  into  Shepes.NUMERIC,  which  holds 
*■  values  to  drew  that  nunber  for  Graphics.  It  updates  DATA_0L0  in  the  process. 

DIGIT  :  Types.UORO; 

STAT_X_LOC  ;  Types. COORDINATE; 

begin 

••STP(0082)  Status. Oisplay.Digits  start 

••  Erase  previous  data 

for  I  in  1  ..  Conf is.statistics_langth  loop 
DATA_OLD(STAT,I).COLOR  :•  Graphics. background.color; 
U0RK_LIST(Types.W0R0_IN0EX(I))  ;■  DATA_OLO<STAT,I); 
end  loop; 

•'tTP(0083>  Status.Oisplay_Digits  rendezvous  with  Graphics(l)  start 
Gr aph i cs . 0 i spl ay . Novel MOVE.PR I OR 1 T Y . UORK.L I ST ) ; 

•-STP(0084)  Status.Oisplay.Oigits  rendezvoua  with  Grephics(l)  end 
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-•  Move  ntM  into  old,  then  display 
STAT_x_LOC  ;■  base.x; 

for  I  in  reverse  1  ..  Config.statistics_length  loop 
DIGIT  :■  NEXT_DATA  mod  10;  ••  get  rightiaost  digit 

DAT A_0U)  ( STAT , I ) .06 JECT : > ( Shapes . P I XEL.HOOE , Shapes .NUMER 1 C( INTEGERID I G I T ) ) > ; 
DATA_0L0(STAT,I}.C0L0R  Graphics.status_color; 

0ATA_0tD(STAT,I).XT_MEW.X  :»  STAT_X_l.0C; 

STAT_X_L0C  :«  STAT^X_L0C  -  Shapes. nunber_uidth;  —  aoving  left 
W0RK_LIST(Types.U0RDJN0EX(l))  :«  DATA_OLD(STAT,I); 

MEXT_DATA  :■  HEXT_DATA  /  10;  —  get  next  digit 

end  !'5op; 

■*STP(0085)  Status. Display_Oigits  rendezvous  with  Graphics(2)  start 
Graphics.Display.MOVE(HOVE_PR10RITY,UORK_LIST); 

**STP(0086)  Status.Oisplay.Oigits  rendezvous  with  Graphics(2)  end 
-■STP(0087}  Status. Oisplay.Oigits  end 
exception 
when  others  » 

Oebug_IO.Put_Line(''Exception  raised  in  Status. Oisplayjligfts"); 
end  0isplay_0igits; 


--  body  of  UPDATE  task 


B<igin 

Initialize; 

loop 

•'STPlOlU)  status  task  start 
■'$TP(0115)  Status  accept  Signal  start 
accept  Signal; 

■'STP(0088)  Status  accept  Signal  end 
Inter rupt_Control .Enable; 

begin  ••  exception  block 

loop 

Internjpt_Control .Disable; 

DISPi.AY_REQUIRE0  :>  not  NODE  .DISPLAYED ; 

NEXT.NOOE  :■  NODE; 

NODE_D I SPLAYED  :■  TRUE; 

Interrupt_Control .Enable; 

if  DISPLAY_REauiRED  then  *-  update  new  status.box 

Update_8ox(NEXT_NOOE ) ; 
end  if; 

for  I  in  STATUS_TYPE' first  ..  STATUS_TYPE'last  loop 
I  nter  rts)t_Cont  rol .  D  i  sabl  e; 

DISPUY_RE0UIRE0  ;■  not  STATUS_CONTROL( I ). DISPLAYED; 

NEXT_DATA  :•  STATUS.CONTROL(I}.DATA; 

STATUS.CONTROLID.DISPUYED  :«  TRUE; 

Interrupt_Control .Enable; 
if  DISPUY  REQUIRED  then 
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0 { spt ay.O < g i ts(NEXT_OATA , 1 } ; 
tnd  if; 

•nd  loop; 

Interrupt^Control .Disable; 

IIEQ_C0WIT  REO^COUMT  -  1; 
exit  uhan  REO.COUNT  >  0; 

Intarrupt_Control .Enable; 
and  loop; 

-•STP(0089)  Status  task  end 
exception 

when  others  «>  Defaug_tO.Put_Line("Exception  raised  in  status  task"); 
end; 

end  loop; 
end  Update.Type; 

end  Status; 
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UNIT:  Sync  Package  Spec. 

Effects:  No  current  use.  Will  provide  greater  synchronize  in  futr. 
Modifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


■*  package  to  synchronize  clocks,  will  contain  a  task  to  call  simulator 
--  clock  entries 

with  Types; 

package  Sync  is 

type  TIME_TTPE'  is  new  Types. WORD; 
end  Sync; 
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I  UNIT:  Targtt  Package  Spec. 

I  Effects:  Provides  structure  for  BOS  Target  managesMnt. 

I  Modifies:  No  global  data  is  modiflad. 

I  Requires:  No  initialization  is  required. 

I  Raises:  No  explicitly  raised  exceptions  are  propagated. 
I  Engineer:  T.  Griest. 


**  package  Target  provides  target  tracking  and  display  management 

with  Types; 
with  Config; 

package  Target  is 

track_stack_sr2e  :  constant  :■  3928; 
track_data_stack_size  :  constant  :>  1506; 

subtype  TARGET_tO_TYP£  is  Types. WORO_{NOEX  range  O..Config.max_^ targets; 

type  TARGET__lTEM_TYPE  is  record  -*1  provides  individual  target  information 
TARGET_I0  :  TARGET_I0_TYPE; 

POSITlpN  :  Types.POSITION_TYPE; 

TAHGET_CLASS  :  Types. TARGET_CUSS_TYPE; 

ervl  record; 

type  TAHGET_LIST_TYPE  is  ’-j  list  of  all  available  targets  items 

array<Types.W0R0_IN0EX  range  <>)  of  TARGET_ITEM_TYPE; 

type  TARGET_MSC_TYPE  is  record  '-|  incoming  message  from  Sensor 
NUMJARGETS  :  Types. W0R0_ INDEX; 

TARGET_LIST  ;  TARGET_LIST_TYPE<Types.TARGETJMOEX_TYPE); 

end  record; 

type  TARGET_STATUS_TYPE  is  record 
ACTIVE  :  BOOLEAN; 

ENGAGED  :  BOOLEAN; 

CUSS  :  Types. TARCET_CLASS_TYPE ; 

end  record; 

for  TARGET_STATUS_TYPE  use  record 
ACTIVE  at  0  range  0..0; 

ENGAGED  at  0  raf>ge  1..1; 

CLASS  at  0  range  2.. 3; 

and  record; 

type  TARGET_OATA_Type  is  record 
STATUS  :  TARC£T_STATUS_TYPE; 

POSITION_NEW  :  Types. POSITION_TYPE; 


-160- 


Demonstration  Project  Final  Report 


POSITlOM_Cn.D  :  Types. POSITION_TYP€; 

end  record; 

type  TARGET_OATA_LIST_TYPE  is 
■r rsy( Types . T ARGET^I MOEX_TYPE )of  TARGET_OATA_TYPE ; 


-  The  TRACK  task  is  used  to  control  all  of  the  target  display  infonaation. 

-  It  accepts  data  from  the  Sensor  and  maintains  it  for  the  Rocket. Control 

-  task. 

task  type  Track_Type  is 
pragma  PRIORITY(Config.track_priority); 
end  Track_Type; 

for  Track_Type'STORAGE_SlZE  use  lNTEGER(Conf ig.bytes_per_storage_unit  * 

t raek_8tack_si ze  > ; 

Track  ,  ;  Track_Type; 


The  Track_Oata  task  is  used  to  buffer  the  most  recent  target  list 
from  the  Target. Track  task  and  provide  it  to  the  Rocket. Control 
task.  It  also  buffers  new  engagements  from  the  Rocket. Control  to 
notify  the  Target. Track  task  that  a  new  target  has  been  engaged. 

Note  that  only  one  neu  target  can  be  engaged  every  update  interval. 

If  the  NEXT_ENGAGE  parameter  is  0,  this  is  an  invalid  TARGETJD,  and 
implies  that  no  new  target  is  engaged. 

task  type  Track_Oata^Type  is 

entry  PutlDATA  ;  in  TARGET_OATA_LIST_TYPE;  —|  put  new  list 

NEXT_ENGAGE  ;  out  TARGET_I0_TYPE;  — |  get  new  engagement 

NEXT.OISENGAGE  :  out  TARGET_ID_TYPE};  -'I  and  disengagement 

entry  GetCOATA  ;  out  TARGET_OATA_LIST_TYPE;  — |  get  new  list 

NEXT_ENGAGE  :  in  TARGET_I0_TYPE;  **1  put  new  engagement 

NEXT_DISENGAGE  :  in  TARGETJD.TYPE);  —I  and  disengagement 

pragma  PRIORITY(Conf ig.track_data_priority); 
end  Track_Oata_Type; 

for  Track_Oata.Jype'STORAGE_SIZE  use  IXTEGERlConfig. bytes _per_stor8ge_u'\i t  * 

track_data_stack_si ze) ; 

Track^Data  :  Track_Oata_Type; 


end  Target;  ■■  package  specification 
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I  UNIT:  Target  Package  Body. 

I  Effects:  Provides  structure  for  BOS  Target  aanaganent. 

I  Modifies:  Mo  global  data  is  aodified. 

I  Requires:  Mo  initialization  is  required. 

I  Raises:  Mo  explicitly  raised  exceptions  are  propagated. 
I  Engineer:  T.  Griest. 


with  Sinulate;  pra^ne  ELABORATECSinulate); 

*■  package  Target  provides  target  tracking  and  display  manageeKnt 
package  body  Target  is 


The  TRACK  task  Is  used  to  control  all  of  the  target  display  Information. 
It  gets  date  from  the  Sensor  and  maintains  it  for  the  Rocket. Control 
task. 

task  body  Track^Type  is  separate; 


-•  The  Track_Oata  task  is  used  to  buffer  the  most  recent  target  list 
--  from  the  Target. Track  task  and  provide  It  to  the  Rocket. Control 
*•  task.  It  also  buffers  new  engagements  from  the  Rocket, Control  to 
--  notify  the  Target. Track  task  that  a  new  target  has  been  engaged. 

■*  Note  that  only  one  new  target  can  be  engaged  every  update  interval. 
**  If  the  NEXT_ENGAG£  parameter  is  0,  this  is  an  invalid  TARCET_I0,  and 
"  implies  that  no  new  target  is  engaged. 

task  body  Track_Data_Type  Is  separate; 
end  Target;  ••  package  body 
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I  UMIT:  Targ_Sup  Task  Body  Subunit. 

I  Effects;  Provides  Simulator  motion  control  for  all  targata. 

I  Modifies:  No  global  data  is  modified. 

I  Requires:  No  initialization  is  required. 

I  Raises:  TARGET_CREATE_ERROR  if  told  to  create  when  max  exceeded. 
I  Engineer:  M.  Sperry. 


with  Calendar; 

with  0ebug_10; 

with  Unchecked_Conversion; 

with  Low_Level_IO; 

with  Time_Stamp; 

use  Low_Level_IO; 

pragma  ELABORAT^(Calendar,  Oebug_IO,  T{me_Staiip); 
separate  (Simulate. Sensor) 
task  body  Targ_Sup_Type  is 

-•  A  task  which  sends  a  list  to  the  caller  describing  new  targets  and 
-•  targets  which  have  been  destroyed.  They  are  described  by  not  being  on 
--  the  list.  Note  that  ney  targets  are  created  first  and  then  those 
-■  that  need  to  be  destroyed  are  processed.  This  task  is  timed  so  that 
••  the  list  is  ready  only  during  100  millisecond  intervals. 


use  Calendar;  --for  visibility  to 

use  Types;  —for  visibility  to  "/"  etc. 


type  HOTION_REC  is  record 
OFFSET  :  Types. METERS; 
COUNT  :  Types. WORD; 
end  record; 


8tart_y 

start_z 

di stance_per_report 

safety_factor 

min_dir_time 


constant 

constant 

constant 

constant 

constant 


Types.METERS  ;»  3960.0; 

Types. METERS  :>  0.0; 

Types.METERS  :«  2.0;  —  meters  in  T  per  report 

Types.METERS  :•  48.0;  —  inner  border  limits 
Types. WORD  ;■  20;  —  direction  travelling  time 


TA«CET_L1MIT 

TARGET_CamT 

TARCET.COUNTER 

CLASS 

TAR0ET_I0 

MOTION 

TEMP 


:  Types. WORD JNOEX  :■  5; 

:  Types. W0R0_INDEX  :«  0;  —  local  count  of  targets 

;  Types. UOR0_IN0EX;  —  Target  index  for  array 

:  Types. TARCET_CLASS_TYPE;  —  type  of  class  for  target 

;  Types. TARGET_IM0EX_TYPE  :■  1;  -  target  id  used 
:  array(Types.TAROETJNOEX_TYPE'first.. 

Types. TARGET_IN0EX_TYPE» last)  of  M0TI0N_REC; 

:  Types. POS1TION_TYPE;  —  for  fixed  coapiter  bug 
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TAR(!ET_CREATE_ERROR  :  EXCEPTION; 
STMT.TINE  :  Calendar. TINE; 

OELAY_PERIOO  :  DURATION; 


function  UORD_TO_ICTERS  is  new  Unchecked_Conversion(Types. WORD, Types. NETERS); 
function  BYTE_TO_UORO  is  new  Unchecked_Conversion(Lou_Level_IO. BYTE, Types. WORD); 


function  RND  return  Types. WORD  is 

counter_two  :  constant  Low_Level_IO.PORT_ADORESS  :>  16#42#; 

DATA  :  Low_Level_IO.BYTE; 

RANOCM_NUMBER  :  Types. WORD; 

begin 

Low_Level_I 0 . Recei ve_Cont ro I < eounter_two , D AT A ) ; 

RANOON.NUMBER BYTE_TO_WORO(DATA); 
return  RANDON_NUMBER; 
end  RND; 

pragme  INLINEIRNO); 


procedure  Initialize  is 

■*  A  procedure  used  to  intialize  the  Simulator's  data  base,  and  start  Ihe 
*■  channel  2  counter  which  is  used  to  determine  the  time  it  takes  for  a  target 
-•  to  switch  directions  as  well  as  which  direction  to  turn. 

timer_cntrl  ;  constant  Low_Level_IO.PORT_AOORESS  ;■  16#43#; 

counter_two  ;  constant  Low_Level_IO.PORT_AOORESS  ;■  16#42#; 

intialize  :  constant  Low_Level_IO.BYTE  :«  16M2#;  *■  mode  2,  channel  2 

start_count  :  constant  Low_Level_IO.BYTE  :•  16#FF#; 

begin 

Low_Leve l_1 0 . Send_Cont rol <  t i  mer_cnt r I , i nt i a I i ze) ; 

Low_L  eve I _1 0 . Send_Control <counter_two, s tar t_co«art ) ; 

Low_L  eve I _l 0 . Send^Cont  ro I ( count er_two , star t_co«it ) ; 

for  I  in  Types. TAROET_IMOEX_TYPE'first.. Types. TARCET_INOEX_TYPE'last  loop 
Simulate. TARGETS(I). ACTIVE  :■  FALSE; 

NOT ION( I). OFFSET  :■  WORO_TO_NETERS<RHO  /  16  •  8); 

NOT  1 0N( I). COUNT  :«  RNO  «  min_dir_time; 
end  loop; 

CLASS  :«  Types.TARCET_CUSS_TYPE'FlRST; 
end  Initialize; 


procedure  Create_New_Target  is 
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-•  A  procedure  used  to  create  a  new  target.  The  first  usable  ID  is  taken 
-•  to  be  the  new  targets  ID.  Also  the  target  class  is  changed  for  every  create. 

FOUND  :  BOOLEAN  :>  FALSE ; 

ID  ;  Types. TARGET_INOEX_TYPE; 

OLO_IO  ;  Types. TARGETJNOEX_TYPE ; 

begin 

--tTP(0090)  Targ_5up. Create  start 
ID  :»  TARGET_ID; 

OLD_ID  :»  TARGET_ID; 
while  not  FOUND  loop 

if  not  Simulate. TARGETSl ID). ACTIVE  then 
Simulate. TARGETS(ID). ACTIVE  :«  TRUE; 
if  CLASS  a  Types. TARGET_CLASS^TYPE' LAST  then 
CLASS  :«  Types.TARGET_CLASS^TYPE' FIRST; 
else 

CLASS  ;»  Types. TARG£T_CLASS^TYPE'SUCC<CLASS); 
end  if; 

Simulate.TARGETS(ID).TARGET_CLASS  ;«  CLASS; 

Simulate. TARGETS(ID). POSITION. X  ;»  WORO_TO_METERS(RND  *  15  ♦  10)  *  8; 
Simulate. TARGETSdO). POSITION. Y  ;*  start^y; 

Simulate. TARGETSIID). POSITION. z  ;«  start_i; 

TARGET_COUNT  !■  TARGET.COUNT  ♦  1; 

TARGET_I0  ;*  ID;  -•  keep  rollover  count  of  TARGET_I0's 

FOUND  :»  TRUE; 
exit; 
else 

ID  :«  ID  ♦  1; 

if  ID  >  Conf ig.max_targets  then 
ID  :■  1; 

if  OLO_IO  a  ID  then 
raise  TARGET_CREATE_ERROR; 

end  if;  --  no  more  room  check 

end  if;  --  wrap  ID  check 

end  if;  --  ACTIVE  cheek 

end  loop; 

--STP(0091)  Targ_Sup. Create  end 
except  on 
when  others  a> 

Oebug_IO.Put_Line("Exception  raised  in  Targ_Sup.Create_New_Target.">; 
end  Create_New_Target; 


--  Targ_Sup  task  body 
begin 

Initialize; 

-•  First  take  the  time. 
START_TIME  :a  Calendar .Clock; 
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loop 

•-$TP(0092)  Targ_Sup  task  start 
SMIIT_TIME  ;•  START^TIME  ♦  Config. interval; 

Then  check  nunber  of  Targets;  if  less  than  awxiosja,  then  add  a  new 
--  Target  to  the  list. 

If  TARGET^COUMT  <  TARGET_LmiT  then 
Create_Mew_Target; 
end  if; 

--  Then  move  each  target. 

for  10  in  Types. TARGET_IMDEX_TYPE'first.. Types. TARGET_HIOEX_TYPE'last  loop 
if  Simulate. TARGETSCID). ACTIVE  then 
Simulate. TARGETSl 10). POSITION. Y  Simulate.TARGETS(ID). POSITION. Y  • 

di stance_per_report ; 

Sifflulate.TARGETS(IO). POSITION. X  :«  Simulate.TARGETS(lD). POSITION. X  ♦ 

NOTION(ID). OFFSET; 

••  Check  for  hitting  against  boirtdaries. 

if  Simulate. TARGETSllO). POSITION. X  >  Conf ig.meters_in_battle_area  then 
Simulate. TARGETSTIO). POSITION. X  ;•  Conf io.meters_in_battle_area  - 

safety_faetor; 

HOTIOii'C  10). OFFSET  :«  -(HOTION(IO).OFFSET);--move  in  opposite  direction 
MOT rON< 10), COUNT  ;«  RNO  ♦  min_dir_time; 
elsif  Simulate. TARGETSt 10). POSITION. X  <  safety_factor  then 
Simulate. tarGETS(IO). POSITION. X  :>  safety.faetor; 

NOTIONl 10). OFFSET  :«  •(M0TI0N(I0).0FFSET);->move  in  opposite  direction 
NOTIONdO). COUNT  ;■  RNO  ♦  min_dir_time; 
end  if; 

MOTIONCIO). COUNT  ;«  MOTIQNi 10). COUNT  •  1; 

if  MOTIONCIO). COUNT  ■  0  then  ••  time  expired,  possibly  change  direction 
MOTIONCIO). COUNT  ;•  RNO  ♦  min_dir_time; 

MOTIONCIO). OFFSET  ;»  UORO_TO_METERSCRNO  /  16  -  «); 
end  if;  -•  timeout  on  direction  check 

end  if;  --  ACTIVE  check 

end  loop; 

••  Then  see  if  any  targets  mode  it  to  the  enemy  line. 

--  These  targets  are  no  longer  the  concern  of  the  BOS.  They 
■■  are  deleted  from  the  list, 
for  I  in  Types, TARGET_lNOEX_TYPE  loop 
if  Simulate.TARGETSC I). ACTIVE  then 
if  Sisulate.TARGErsci). POSITION. Y  <  40.0  then 
TARCET_COUNT  :»  TARGET_COUMT  -  1; 

Simulate. TARGETSCI). ACTIVE  :>  FALSE; 
end  if; 
end  if; 
end  loop; 

■■  Finally  move  the  list  into  the  target  list  kept  by  the  target  spec. 
--STPC0093)  Tsrg_Stp  accept  Mext_Target_Msg  start 
accept  Next_Target_MsgCDATA  :  out  Target. TARGET_MSG_TYPE)  do 
TARG£T_COUNTER  ;»  0; 
for  I  in  Types.TARCET_INOEX_TYPE  loop 
if  Simulate. TARGETSCD.ACTIVE  then 
TARG£T_COUNTER  :■  TARCET_COUNTER  ♦  1; 
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TEMP  :«  Simulate. TARGETS(I). POSITION;  ••'fixed  coapUer  code  bug 
DATA. TARGET_UIST<TARG£T_COUNTER). POSITION  ;■  TENP; 

DATA .  TARGET_L  I  ST  (TARGET_COUNTER  ) .  TARGET_CUSS  :■ 

Slmulate.TARGETS( I ) .TARGET_CLASS; 
DATA.TARGET_LIST{TARGET_COUNTER).TARGET_ID  ;■  I; 
end  if; 
end  loop; 

TARGET_COUNT  ;»  TARGET_COUMTER; 

DATA.NUM_TARGETS  TARGET_COUNTER; 
end  Next_Tar9et_M8g; 

•-STP(0094)  Targ_Sup  accept  Mext_Target_Hsg  end 
DELAY_PERIOO  :■  START_TIHE  •  Calendar. Clock; 
if  DELAY_PERIOO  <  0.0  then 
START_TIME  ;■  Ca lender. Clock ; 
end  if; 

••STP(0095)  Targ_Sup  end 
delay  DEUY.PERIOO; 
end  loop; 

••  accept  Clock(Time  :  in  Sync.TINE_TYPE);  ••TBO 
end  Targ_Sup_Type; 
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UNIT:  Track  Task  Body  Si^unit. 

Effacts:  Provides  all  target  tracking  and  display  for  BOS. 
Modifies:  No  global  data  is  andified. 

Requires:  No  initialization  is  raquired. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer;  T..  Griest. 


with  Graphics; 

with  Shapes; 

with  Interrupt_Control; 

with  Grid_to_Pixel; 

with  SiMulate; 

with  Debug_IO; 

with  Status; 

with  Time_Stainp; 

pragma  ELABORATElGraphics, Shapes,  Interrupt  Control, Grid  to  Pixel, 
Simulate,  Debug.IO,  Status,  Timers tamp); 


separate  (Target) 

••  The  TRACK  task  is  used  to  control  all  of  the  target  display  information. 
••  It  accepts  data  from  the  Sensor  and  maintains  it  for  the  Rocket. Control 
task. 


task  body  Track.Type  is 
use  Types; 

package  Sensor  renames  Simulate. Sensor;  make  simulation  transparent 


use  Types; 

TARGET.MSG 

MOVE_TARGETS 

NOVE.INOEX 

OESTROYEO 

CREATED 

PI)(EL_POINT 

TARGETS 

NSG.INOEX 

NEXT^ENCAGED 

NEXT^DtSENGAGEO 

COLOR 

ENGACE.FUG 

CUSS 

POSITION 

begin 


••  for  operators  only 
TARGET_MSG_TYPE; 

Graph i cs .NOVELL I ST_TTPE ( Types . TARCET_INDEX_TYPE ) ; 
Types.  WORD  JNOEX; 

Types. WORD; 

Types. WORD; 

Shapes. PIXEL; 

TARGET_OATA_L I ST_TTPE ; 

Types. WORD  JNOEX; 

Types. UORO_INOEX;  ••  0  if  no  new  engagement 
Target. TARG£T_IO_TTPE;-*  keep  track  of  disengagements 
Graph ics.COLOR.TYPE; 

BOOLEAN; 

Types .  TARGET_CUSS_TYPE  ; 

Types.POSITION_TYPE;  --  temp  for  making  changes 


--  INITIALIZATION 


for  I  in  TARGETS' range  loop 

TARCETSf I ). STATUS  :>  (FALSE, FALSE, UNKNOWN);  •>  init  to  default 
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tnd  loop; 
loop 

••STP(0096)  Track  task  start 
••STP<0097}  Track  rendezvous  with  Targ_Sijp  start 
Sensor. Targ_Sup.Hext_Tar9et_Nsg(TARGET_MSG); 
•-STP(0098)  Track  rendezvous  with  Targ_Sup  end 

'•  Zero  out  counters 


CREATED  :>  0; 

DESTROYED  :*  0; 

•  Maintain  history  information. 

•  Go  through  each  target  to  examine  its  new  status 

HSGJMDEX  :■  1; 

MOVE.INOEX  :a  0; 

for  TARGET.ID  in  TARGETS'RANGE  loop 

if  TARG£TS<TARCET_10).STATUS.ACTIVE  then 

if  MSG_tNDEX  >  TARGET_MSG.NIM_TARGETS  or  else 
T AR6ET_MSG . TARGET.L  I ST(MSG_I  NOEX ) . TARGET, tO 

/■  TAR6ET_I0  then  ••  target  destroyed 

■*  Target  has  been  destroyed,  keep  local  accusul'ation  of  destroyed 
••  targets,  and  add  to  list  for  Display  task  to  erase  target. 


DESTROYED  :>  DESTROYED  >  1; 

••  mark  as  inactive  (ACTIVE  «>  FALSE,  ENGAGED  »  FALSE,  CLASS  a>  UNKNOWN) 
TARGETS(TARGET,IO). STATUS  (FALSE,  FALSE,  Types.UNKNOWN); 

MOVE_IHOEX  ;»  NOVE_IMOEX  ♦  1; 

PtXEL,POINT  :«  Grid_To,Pixel(TARGETS(TARGETJO).POSITION_MEU); 

COLOR  :>  Graphics. background_color; 

MOVE_TARGETS(MOVE_INOEX)  ;•  (PIXEL_POINT, 

PIXEL_POINT, 

( Shapes . P 1 XEL.MOOE , Shapes . TARGET ) , 
COLOR); 

else  ■*  move  the  target 

--  Found  a  current  existing  target  in  the  latest  sensor  report, 

■■  update  target  information  and  add  it  to  move  list. 

POSITION  ;«  TARCET_MSG.TARGET_LIST(MSCJNDEX).P0SIT10N; 

MOVEJNOEX  :«  MOVEJNOEX  ♦  1; 

CUSS  :■  TARGETS(TARGET_IO). STATUS. CUSS; 

ENGAGE.FLAG  :*  TARGETS(TARGET_IO). STATUS. ENGAGED; 

COLOR  :•  Graphics. target_color(CLASS,  ENGAGE.FUG); 
MOVE_TARGETS(MOVE,INOEX)  :■ 

(XY,OLO  »  Grid_te_Pixel(TARGETS(TARGCTJD).POSIT10N_NEU), 
XT_NEW  ■>  Orid_to_Pixel(POSITION), 
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OBJECT  »  (Shapes. PIXEL.NOOE.Shapes.TABGET), 

COLOR  »  COLOR 

); 

TARGETS(TARGET_ID). POSITION JOLO  :>  TAR(i£TS(TARG£TJD).POSITION_HEU; 
TARGETS<TARGETJO).POSITION_NEW  :»  POSITION; 

NSGJNOEX  :«  MSG.INOEX  *  1; 
end  if;  -■  new/old  target  check 

else  *■  this  target  wasn't  previously  active 

if  MSG_INOEX  <a  TARGET_MSG.NUM_TARGETS  and  then 
TARG£T_MS6. TARGET.L  I ST (NSG.I  NOEX } . TARGET. 10 

«  TARGET.IO  than  —  new  target 

New  Target  has  been  created,  set  status  and  put  it  on  display 

CREATED  :>  CREATED  *  1; 
mark  as  active 

TARGETS<TARGET_ID). STATUS  :« 

(TRUE,  --  ACTIVE 

,  FALSE,  -*  Engaged 

TAR0ET.NSG.TAR0ET_L1ST(NSG_IMDEX).TARGET_CLASS);  --  class 
TARGETS(TARGET.IO).POSITION_OLO  :«  —  set  both  Old  and  new 

TARGET.NSG . TARGET.L I ST<NSG.INOEX ) . POS I T ION ; 
TARGETS(TARGETJO).PQSITION.NEU  :> 

TARGET.MSG . TAROET.L I ST (MSG.I MOEX) .POSITION; 
NOVE.INOEX  :■  NOVE.INDEX  ♦  1; 

CLASS  :■  TARGETS(TARGET JO). STATUS. CLASS; 

ENGAGE.FLAG  :«  TARGETS(TARGET.IO).STATUS.ENGAGEO; 

COLOR  :«  Graphics. target_color(CLASS,  EHGAGE.FLAG); 
NOVEJARGETS(NOVEJNOEX)  :> 

(XY.OLO  ■>  Grid_to_Pixel(TARGETS(TARGET_IO).POSITION_OLD), 
XY.NEW  ■>  Grid_to_Pixel(TARGETS<TARGETJO).POSITION_NEU), 
OBJECT  »  (Shapes. PlXEL.NODE,Shapes.TARGET), 

COLOR  »  COLOR 

); 

NSG.INDEX  :>  NSG.INOEX  *  1; 

end  if;  end  of  new  target  check 

end  if;  .  active  check 

end  loop; 

Now  update  status  if  any  created  or  destroyed 

if  CREATED  /•  DESTROYED  or  DESTROYED  >  0  then 
I nter rupt.Control .0 i sabl s; 

Status. STATUS.CONTROL (Status . TRACKED ) .DATA  :« 

Status. STATUS_CONTROl(Status.TRACKEO).OATA  ♦  (CREATED  •  DESTROYED); 
Status. STATUS_CONTROL(StStuS.rRACKEO).DISPLAYCO  :>  FALSE; 

Status. STATUS_CONTROL(StatUS.OESTROYEO). DATA  :■ 

Status. STATUS.CONTROL(StatUS.OESTROYED).OATA  «  DESTROYED; 
Status.STATUS_CONTROL(Status.OESTROYEO).OISPLAYEO  :•  FALSE; 
Status.REO.COUNT  :•  Ststus.REO.COUNT  *  1; 
if  Status. REQ  COUNT  •  1  then 
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•-STP(0099)  Track  rendezvous  with  Status  start. 

Status.Updatc.Signal; 

•■STPtOlOO)  Track  rendezvous  Mith  Status  end 
end  if; 

lntcrrupt_Control .Enable; 
end  if; 

■•STPCOIOI)  Track  rendezvous  with  Track_Data  start 

Target . Track.Data. Put ( TARGETS , NEXT_ENGAGEO , NEXT  J>  t  SENGAGED  > ; 

**  send  copy  to  Rocket. Control 
-•STP(0102)  Track  rendezvous  with  Track^Data  end 
if  MEXT_EMGAGED  >  0  then 

TARGETSINEXT.ENGAGED). STATUS. ENGAGED  :>  TRUE;  •-  set  engaged 
end  if; 

if  NEXT.D I SENGAGED  >  0  then 
TARGETS(NEXT_OtSENGAGED). STATUS. ENGAGED  :«  FALSE; 
end  if; 

-•STP(0103)  Track  rendezvous  with  Graphics  start 
Graph i cs .D i spl ay .Hovel Gr aph i cs . LOU ,  HOVE.TARGETSl 1 . .MOVE.I NOEX ) ) ; 
••STP(0104) 'Track  rendezvous  with  Graphics  end 
*-STP(0105)  Track  task  end 
end  loop; 
exception 
when  others  «> 

Oebug_IO.Put_Line("TRACK  termination  due  to  exception."); 
en>i  Track_Type; 
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UNIT:  Track_Oata  Task  SiAunit. 

Effects:  Provides  buffering  of  target  trscking  data  between  the 
Track  task  and  the  Control  task  for  rocket  engagement. 
Nodifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer:  T.  Griest. 


with  Time_Stainp; 
with  lnterrupt_Control; 

pragma  ELABORATE(Time_Stanp, Interrupt_Control ); 
separate  (Target) 

••  The  Track_Data  task  is  used  to  buffer  the  most  recent  target  list 
••  from  the  Target. Track  task  and  provide  it  to  the  Rocket. Control 
-*  task.  It  also  buffers  new  engagements  from  the  Rocket. Control  to 
-•  notify  the  Target. Track  task  that  a  new  target  has  been  engaged. 

Note  that  only  one  new  target  can  be  engaged  every  update  interval. 
••  If  the  NEXT_ENGAGE  parameter  is  0,  this  is  an  invalid  TARGET^ID,  and 
••  implies  that  no  new  target  is  engaged. 


task  body  Track_Oata_Type  is 
use  Types; 

BUFFEREO_OATA  :  Target. TARGET_0ATA_L I ST_TYPE; 

BUFFEREO_EHGAGE  :  Target. TARGET_ID_TYPE; 

BUFFERE0_0ISENGACE  :  Target. TARGET_IO_TYPE; 

DATA.COUNT  :  Types. UORO  0; 

begin 

••  Initialize  local  copy  of  data 
-•  initialize  all  target  status  to: 

(ACTIVE  a>  FALSE,  ENGAGED  »>  FALSE,  CUSS  »  UNKNOWN) 

BUFFERED.EHGAGE  :■  0;  --  default  is  no  new  engagement 

for  I  in  BUFFEREO.OATA' range  loop 
BUFFERED_0ATA( I). STATUS  :-  (FALSE,  FALSE,  Types. UNKNOWN); 
end  loop; 
loop 
select 

accept  PutlOATA  ;  in  TARGET_OATA_LIST_TYPE; 

NEXT_ENGAGE  :  out  TARGET_I0_TTPE; 

NEXT_0ISENCA0E  :  out  TARGET_I0_TYPE)  do 
•*tTP(0106)  Trackdat  accept  Put  start 
Interrupt_Control .Disable; 
lUFFERED.DATA  :>  DATA; 

I nt er rv^t_Cont r 0 I . Enabt e ; 
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MEXT_EMGAGE  :•  BUFFEREO_EMGACE; 

HEXT_0ISENGAGE  ;■  BUFFERED_OISEMGAGE; 

DATA_COUMT  :«  1; 

--$TP<0107)  Trackdat  accept  Put  end 
end  Put; 
or 

when  DATA  COUNT  >  0  »> 

accept  Get(0ATA  :  out  TARGET.DATA.LIST.TYPE; 

HEXT_EHGAGE  :  In  TARGET_ID_TYPE; 
MEXT_DISEMGAGE  :  in  TARGET_IO_TYPE)  do 
--$TP(0108)  Trackdat  accept  Get  start 

I nt er rupt_Con t r 0 I . 0 i sab I e ; 

DATA  :«  BUFFEREO.OATA; 
lntarrupt_Control .Enable, • 

BUFFERED.ENGAGE  :«  HEXT_EHGAGE; 

BUFFERED_OISEMGAGE  :■  MEXT_OISENGAGE; 

OATA.COUNT  ;■  0; 

— $TP(0109)  Trackdat  accept  Get  end 
end  Get; 
end  select; 
end  loop; 

end  Track_Data_Type; 
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UNIT:  Traject  Function  Spec. 

Effects:  Computes  rocket  motion  based  on  previous  motion  and 
ainpoints  received  in  guidance  messages. 

Modifies:  No  global  data  is  modified. 

Requires:  No  initislizstion  is  required. 

Raises:  No  explicitly  raised  exceptions  sre  propagated. 

Engineer:  T.  Griest. 


•*  Traject:  Is  the  trajectory  planner  for  taking  an  Azimuth.  Elevation 
*■  X.r.Z  position  and  constant  velocity  and  producing  a  new 

position 

with  Types; 

function  TrajectlPOSP  :  Types. POSITION_TYPE;  AIMPOINT  :  Types.AIMPOINT_TYPE) 
return  Types.POSITlON_TYPE; 
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UNIT:  Traject  Function  Body. 

Effects:  Computes  rocket  motion  based  on  previous  motion  and 
aimpoints  received  in  guidance  messages. 

Modifies:  No  global  data  is  modified. 

Requires:  No  initialization  is  required. 

Raises:  No  explicitly  raised  exceptions  are  propagated. 

Engineer;  T.  Griest. 


--  Traject:  Is  the  trajectory  planner  for  taking  an  Azimuth,  Elevation 
-■  X,Y,Z  position  and  constant  velocity  and  producing  a  new 

position 

with  Math; 
with  Time^Stamp; 

pragma  ELASORAT6<Math,  Time_Staap); 


function  TrajeetiPOSO  ;  Types.POSITION_TYPE;  AIMPOINT  ;  Types.AIMPOIMT_TYPE) 
return  Types. POSITION_TYPE  is 
use  Types;  --  for  operators 

velocity  ;  constant  :«  20;  -•  meters  per  interval 


SCALE 

XO,  YO,  ZO 
X0_S<3 
ELEVATION 
AZIMUTH 
DIRECT I ON_X 
DIRECT  I ON^Y 
DIRECTION  Z 


Types.LONG.FlXED; 
Types.LCNG.FlXED; 
Types.LONG_FlXED; 
Types. BAM; 

Types. BAM; 
INTEGER; 

INTEGER; 

INTEGER; 


--  XO  •*  2 


MEU_POS  ;  Types.POSITIONJYPE; 
begin 

--$TP(0110)  Traject  start 
if  AIMPOINT. AZIMUTH  »  0  then 
0IRECT10N_Y  ;«  1; 

--  AZIMUTH  ;»  AIMPOIHT, AZIMUTH; 
else 

0IRECTI0N_Y  :■  -1; 

AZIMUTH  :«  -AIMPOIHT.AZIMUTH; 
end  if; 


if  aba  AINPOINT.AZIHUTH  <■  16384  then 
DIRECTION_X  ;«  1; 

else 

01RECTI0N_X  ;■  -1; 

AZIMUTH  ;«  (32767  -  AZIMUTH)  ♦  1; 
end  if; 
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--  If  AIMPOIMT. ELEVATION  >«  0  then 
0IRECTI0tl_2  ;■  1; 

ELEVATION  ;«  AINPOINT. ELEVATION; 
*•  else 

0IRECTI0N_2  ;«  -1; 

ELEVATION  ;«  -AIMPOINT. ELEVATION; 
--  end  if; 


TO  :»  1.0; 

XO  :«  Math. TanlAIMPQINT. AZIMUTH); 
if  XO  »  0.0  then 
XO  ;»  Types. sqrt_Urge_ni«ber; 
else 

XO  ;»  Types. LONG_FlXED(Types.LONG_FlXEO(1.0)/XO); 
end  if; 

X0_SQ  :«  Types. LONG^FIXEOIXO  *  XO); 

ZO  :«  Types. LONG_fI«0<Math.Tan<AIMPOINT. ELEVATION)  * 

Math.Sqrt(XO_SQ  ♦  Types. LONG_FIXED(1.0))); 

if  ZO  »  Types. sqrt_large_nuRR)er  then 
20  ;«  Types. sqrt_l arge_nui<)er; 
end  if; 

SCALE  :»  Math.SqrtlTO  ♦  XO^Sq  ♦  Types. LON0_FlXE0<Z0*20)); 

NEW_POS.X  :«  Types. METERSl velocity  *  OIHECTION_X  *868X0/  SCALE)  ♦  POSO.X 
NEW.POS.Y  :«  Types. METERS<Types.LONG_FIXEO<velocity)  / 

SCALE)*OIRECTION_T  ♦  POSO.Y 

MEW_POS.Z  :a  Types. METERSlvelocity  *  20  /  SCALE)  ♦  POSO.Z; 

-•$TP(0111)  Traject  end 
return  NEU_POS; 
end  Traject; 
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•|  UNIT:  Types  Package  Spec. 

^ I  Effects:  Provides  general  purpose  data  types. 

-|  Modifies:  No  global  data  is  modified. 

•|  Requires:  No  initialization  is  required. 

•|  Raises:  No  explicitly  raised  exceptions  are  propagated. 
•|  Engineer:  T.  Griest. 


--  Date  :  10-10-88 
--  Purpose  : 

The  purpose  of  Types  is  to  provide  comaon  project  specific  data  types  that 
••  are  not  related  to  any  particular  application  area. 

with  Config; 

package  Types  is 

type  WORD  is  range  -32768  ..  32767; 
for  UORO'size  use  16; 

type  UORO_INOEX  is  range  0  ..  32767; 
for  U0R0_IM0EX'size  use  16; 

subtype  M0R0_C0UNT  is  UORO  range  0  ..  32767; 

subtype  R0CKET_IN0EX_TYPE  is  W0R0_1N0EX  range  1.'.Coofig.max_rockets; 
subtype  TARGET^INOEX_TTPE  is  W0R0_IN0EX  range  1..Config.inax_targets; 

subtype  COOROINATE  is  Types.WORO; 
subtype  REL.COOROINATE  is  Types.WORO; 


type  METERS  is  delta  0.125  range  -Config. meters_in_battle^8rea  .. 

Conf  i  g.<Beters_i  n_bat  t  le_area ; 

type  LOMO.FIXED  is  delta  0.015625  range  -33_556_432.0.. 33^554.431. 0; 
for  I.ONU.FIXEO'sire  use  32; 

sqrt.large.nunber  :  constant  :>  2508.0;  -•  approx  sqrtdONG.FIXEO' last>/4 

type  POSITION.TYPE  is  record  --|  for  absolute  position 

X  :  METERS;  --|  assume  battlefield  oriented  ENU 

Y  :  METERS; 

Z  :  METERS; 

end  record; 

type  POSIT lON.PAlR.TYPE  is  record  --|  X,Y,Z  in  maters 
TARGET.OLO  :  Types.POSITION.TYPE; 

TARGET.NEU  :  Types.POSITION.TYPE; 
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ROCKET.OLD  ;  Types. POSIT I0N_TYPE; 

ROCKET_MEW  :  Types. POSIT I0N_TYPE; 

end  record; 

type  BAM  is  range  -32768  ..  32767;  --I  binary  angle  laaasureinent  32768/180 

-•|  East  North  Up  origins  (0) 


type  AlMPOIMT_TYPE  is  record 
AZIMUTH  :  BAM; 

ELEVATION  :  BAM; 
end  record; 

subtype  DISTANCE  is  METERS  range  0.0  ..  Conf ig.meters_in_battle_area; 


-•  T80  •  Mein  Battle  Tank 

--  SA9  -  OASKIN  surface  to  air  missle  launcher 

--  BMP2  -  Infantry  Combat  Vehicle 

type  TARGET^CLASSJYPE  is  (UNKNOWN,  T80,  SA9,  BMP2); 

end  Types; 
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20  Appendix  I  -  Distributed  Runtime  Source  Code 


The  source  code  for  the  distributed  runtime  uses  an  8086  family 
assembly  language  code.  It  is  divided  into  modules  which  implement 
the  major  functional  areas.  These  include:  prog;ram  linkage,  runtime 
routines,  network  setup,  network  I/O,  and  vendor  runtime 

interface. 
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.XLIST 


FILE:  DA.DEF.ASM 

Distributed  Ada  ■  Definitions 

Definitions  for  system  values 


Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
Derivation  :  LabTek  Distributed  Ada  VI. 0 

This  Distributed  Ada  Runtime  Inherits  the  LabTek  copyright. 
The  following  copyright  must  be  Included  in  all  software 
utilizing  this  Ada  Runtime. 

Copyright  1989  by  LabTek  Corporation,  Woodbridge,  CT,  USA 

Permission  to  use,  copy,  modify,  and  distribute  this 
software  and  its  docunentation  for  any  purpose  and  without 
fee  is  hereby  granted,  provided  that  the  above  copyright 
rMtice  appear  in  all  copies  and  that  both  that  copyright 
notice  and  this  permission  notice  appear  in  supporting 
docunentation,  and  that  the  name  of  LabTek  not  be  used  in 
advertising  or  publicity  pertaining  to  distribution  of  the 
software  without  specific,  written  prior  permission. 

LabTek  makes  no  representations  about  the  suitability  of 
this  software  for  any  purpose.  It  is  provided  "as  Is" 
without  express  or  InpUed  warranty. 

Disclaimer 

This  software  and  Its  docunentation  are  provided  "AS  IS"  and 
without  any  expressed  or  implied  warranties  whatsoever. 

No  warranties  as  to  performance,  merchantability,  or  fitness 
for  a  particular  purpose  exist. 

in  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct.  Indirect,  consequential 
or  inconsequential  damages  or  lost  profits. 

; ; ; ; ;;;;;;;;;;;;  E  mo  -  prologue  ; ; ; ; ; ,-  ,*  ,* ; ; ; ;;;;;; ; ; ; ; ; ; ; ; ; ; 


NETWORK  MESSAGE  CONTROL  FIELD  VALUES 


dest Inat 1 on_addr 

•qu 

0 

source_addr 

e<^ 

6 

RCP 

equ 

12 

priority 

•qu 

14 

sequence 

•qM 

16 

data_length 

•qu 

18 

Ethernet  address  of  receiver 
Ethernet  address  of  sender 
Receive  Control  Pointer  offset 
Ada  priority  (not  used  at  present) 
Packet  Sequence  Counter 
length  of  data  field 
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da£a_f ield 

equ 

20 

;  Data  fie(d(s) 

1 

;  Offsets  from  Receive  Pointer 

(AT  BUFFER'^RCP)  to  various  fields 

f 

DEF  and  offset 

equ 

0 

;  coanand  field 

0EF_pid_of fset 

equ 

2 

;  processor  ID 

DEF  tid  offset 

equ 

A 

;  task  ID 

OEF_eid_offset 

equ 

6 

;  entry  ID 

OEF_reply_offset 

equ 

8 

;  Reply  message 

;  Offset  from  list 

pointer  to  next  node  pointers 

DEF_Mext_Ptr 

e<^ 

2 

;  offset  to  next  pointer  in  buffer 

;  TCB  Offsets 

DEF_TCB_EIO 

equ 

6 

;  Offset  to  Entries  in  TCB 

OEF_TCB_ENTRY_sriE 

e<Ai 

4 

;  four  bytes  per  Entry 

DEF_TCB_REPLY 

equ 

14 

;  offset  to  rendezvous  reply  pointer 

;  PROCESSOR  /  TASK 

/  ENTRY  IDs 

;  Note:  PIOs  increment  by  6, 

;  TIOs  and  ElOs  by  2. 

;  TASK  10s  are  unique. 

UE  F_a  1  pha_'iddress 

struc 

f 

db 

2. 

96,140,  68,  82,  9 

db 

2, 

96,140,  71,  99,  85 

DE F_8 1 pna_address 

ends 

DEF  bravo  address 

struc 

db 

2. 

96,140,  58H,  35H,  68H 

db 

2. 

96,140,  48H,  S1H,  60H 

0EF_br8vo_address 

ends 

0?F_pid_.jlpha 

equ  0 

;  Primary  Processor 

0EF_pid_bravo 

equ  6 

;  Secondary  Processor 

;  COMMANDS  received 

via  massages 

0EF_elab_begin 

equ  0 

0EF_elab_end 

equ  2 

OE  F_request_ent  ry 

equ  4 

0EF_aceept_conplete 

equ  6 
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Parameter  Passing  convention  to  runtime  network 'msg  routines. 
Standard  Call  Frame: 


0EF_task_id 

a<pi 

6 

0EF_TCP 

equ 

8 

0EF_Entry 

equ 

8 

OEF_parameters 

equ 

10 

DEF_param_count 

equ 

0 

OEF  _p8ram__offset 

equ 

0 

OEF_param_segment 

equ 

2 

DEF_param_length 

e«^ 

4 

DEF_param_descriptor  equ 

6 

OEF_local_task_id 

equ 

6 

0EF_l oca l_ent ry^i d 

equ 

6 

;  BP  «  6 

;  BP  'T  8  Transmit  control  pointer 
;  BP  8  (also  used  for  entry  ID) 
;  BP  ♦  10 

relative  to  parameters  (In/Out) 

followed  by  sequent 

relative  to  offset 
#  of  bytes  per  parameter 

buffer  offset  for  task_id 

offset  from  BP  in  local  end  rendezvous 


REMOTE  ENTRY  CALL 
Low  address 


task  10 *  * 

•••••♦♦••OX 

CONTROL  PTR  • 


IN  Paranwtep  Coi^it  • 
IN  PARM1  OFFSET 


IN  PARM1  SEGMENT  * 

IN  PARM1  LENGTH  * 


*  IN  PARMn  OFFSET 

*  IN  PARMn  SEGMENT 

*  IN  PARMn  LENGTH 


BP>6 

♦8 

etc. 


Note:  (Xit  parameters  are  accessible  via  the  buffer  decriptor 
pointed  to  by  (BX). 
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REMOTE  END  RENDEZVOUS 

Low  oddress  •  TASK  ID  • 


CONTROL  PTR 


•  OUT  Porametop  Count  • 


BP^ 

♦8 

etc. 


•  OUT  PARM1  OFFSET *  * 

••***•**««••*••***«*•*«•• 

•  OUT  PARM1  SEGMENT  * 

**••*•**••«  »**«»«*••**••* 

•  OUT  PARM1  LENGTH  • 


*  OUT  PARMn  SEGMENT  • 


*  OUT  PARMn  LENGTH  * 

•»<>•«•  ■  «  «  »«»«—«•  «»«««»»« 


Note:  Out  parameters  are  accessible  via  the  buffer  decriptor 
pointed  to  by  (BX). 


SELECT 

Low  address  *  TASK  ID  *  BP^ 


*  NUMBER  OF  ENTRIES  *  «8 


*  ENTRY  1  *  etc. 

*  ENTRY  2  * 


*  ENTRY  N  * 
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Note:  On  return,  AX  contains  which  entry  was  selected,  BX  points 
to  buffer  descriptor  or  LOCAL  DATA  address  if  descriptor  next 
pointer  is  non-null. 


Task  Control  Block  Layout 

TASK_[D:  each  block  is  pointed  to  by  a  unique  ID,  which  is  the 

offset  (address)  within  the  DA  code  segment  of  the  TCB 
for  that  TASK. 


Sync_Semaphore:  The  sync  seaiaphore  is  used  to  suspend  (or  resune) 
execution  of  the  associated  task  for  rendezvous. 

Entry_Table:  Ihe  Entry  table  provides  a  record  for  each  of  the 
entries  defined  in  the  task.  The  record  contains: 

WAITING  :  flag  indicating  that  the  accepting 
task  is  waiting  for  an  entry  call 
for  this  entry. 

NEXT_PTR:  Head  of  buffer  descriptor  linked  to 
this  entry. 


.LIST 
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.XL 1ST 


FILE:  DA^HU.ASM 

Distributed  Ada  -  Hardware  Definition  Include  File 

Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
Derivation  :  LabTek  Distributed  Ada  Vi.O 

This  Distributed  Ada  Runtime  inherits  the  LabTek  copyright. 
The  following  copyright  must  be  included  in  all  software 
utilizing  this  Ada  Runtime. 

Copyright  1989  by  LabTek  Corporation,  Uoodbridge,  CT,  USA 

Permission  to  use,  copy,  modify,  and  distribute  this 
software  and  its  docunentation  for  any  purpose  and  without 
fee  is  hereby  granted,  provided  that  the  above  copyright 
notice  appear  in  all  copies  and  that  both  that  copyright 
notice  and  this  permission  notice  appear  in  supporting 
docusentation,  and  that  the  naste  of  LabTek  not  be  used  in 
advertising  or  publicity  pertaining  to  distribution  of  the 
software  without  specific,  written  prior  permission. 

LabTek  makes  no  representations  about  the  suitability  of 
this  software  for  any  purpose.  It  is  provided  "as  is" 
without  express  or  implied  warranty. 

Oi sclaimer 

This  software  and  its  documentation  are  provided  "AS  IS"  and 
without  any  expressed  or  inplied  warranties  whatsoever. 

Ko  warranties  as  to  performarKe,  merchantability,  or  fitness 
for  a  particular  purpose  exist. 

In  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damages  or  lost  profits. 

e no - prol ocue  ; ; ; ; ; ; ; ; ; ; ; ;;;;;;;;;; ; : ; ; ; ; ; ; ; ; ; 


Ethernet  Board  Hardware  Configuration 


t 

base 

equ 

310H 

i 

:  base  address  of  board 

veetor_fHsi*>er 

e<W 

SH 

;  vector  muter  for  board 

netjsemory  ,seg 

equ 

OOCOOH 

;  address  of  ethernet  memory 

net_memofy_s i ze 

equ 

2000H 

;  8K  bytes 

LAN  Controller  Page  0  registers 


NlC_cr  equ  base  0;  **  control  register  of  NIC 
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NIC_p4tart 

equ 

base  *  1; 

HlCjMtop 

equ 

base  ♦  2; 

MlC_bndy 

equ 

base  3; 

NlC_tpsr 

e<^ 

base  *  4; 

NIC.tbcrO 

equ 

base  5; 

NIC_tbcr1 

equ 

base  *  6; 

NlCJsr 

equ 

base  ♦  7; 

NlC_rsarO 

equ 

base  *  8; 

NlC.rsarl 

equ 

base  *  9; 

HlCj-bcrO 

equ 

base  *  iO 

MlC_rber1 

equ 

base  *  11 

HlC_rcr 

equ 

base  ♦  12 

»IC_tcr 

equ 

base  *  13 

NlC_dcr 

base  *  14 

NIC_imr 

base  ♦  15 

••  page  start  register 
*•  page  sto^  register 
>•  boundary  register 
*•  transsiit  page  start  register 
■■  transsiit  byte  count  rgtr  hi 
*•  transsiit  byte  count  rgtr  lo 
*■  interrt4>t  status  registar 
*•  resnte  start  address  rgtr  lo 
remote  start  address  rgtr  hi 
*■  remote  byte  count  rgtr  lo 
--  remote  byte  count  rgtr  hi 
"  receive  configuration  rgtr 
**  transmit  configuration  rgtr 
data  configuration  register 
--  interrrupt  mask  register 


controller  page  1  registers  •  NIC  address  setup  registers 
These  registers  are  written  to  establish  what  the  actual 
physical  address  will  be. 


phys_addreas_0  equ  base  ♦  1; 
phys_sddress^1  equ  base  *  2; 
phys_address_2  equ  base  *  Z; 
phys_8ddreas_3  equ  base  ♦  4; 
phys_addressjli  equ  base  *  5; 
phys_8ddress_5  equ  base  ♦  6; 
NlC_curr  equ  base  ♦  7; 


physical  address  registers. 
These  registers  are  accessed 
via  Nic_cr  bits  7,6  ■  0,1. 

LAN  registers  are  accessed 
via  cntrl  bits  3,2  •  0,0. 

only  written  once  during  init 


Controller  Page  2  '  Ethernet  PROM  ADDRESS  memory 
These  locations  contain  the  "preferred"  address  as  contained 
in  PROM.  These  will  typically  be  copied  to  the  physical 
address  registers  above  <page  1). 


prom_sddress_0 

base  *  0; 

••  station  address  0 

prom_addres8_1 

base  >  1; 

-*  station  address  1 

pram_address_2 

equ 

base  *  2; 

■*  station  address  2 

prom_address_3 

equ 

base  *  3; 

■■  station  address  3 

prom_addre8s_4 

e<^ 

base  ♦  4; 

-■  station  address  4 

prom_addres8_5 

equ 

base  *  5; 

--  station  address  5 

$ 

;  Gate  Array  registers  (note:  offset  of  400H) 

# 

pstr 

base  *  400H; 

--  page  start  register 

papr 

equ 

base  *  401 H; 

'■  page  stop  register 

dqtr 

base  *  402H; 

••  drq  timer  register 

bcfr 

•qu 

base  ♦  403H; 

base  configuration  register 

pcfr 

equ 

base  >  404H; 

'•  prom  configuration  register 

gacfr 

•dM 

base  *  40SH; 

'•  ga  configuration  register 
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cntrl 

e<hJ 

base 

♦ 

406H; 

streg 

equ 

base 

♦ 

407H; 

idefr 

e«^ 

base 

♦ 

408H; 

damsb 

equ 

base 

♦ 

409H 

dalsb 

base 

♦ 

40AH; 

vptr2 

equ 

base 

♦ 

40BH^ 

vptrl 

equ 

base 

♦ 

40CH 

vptrO 

equ 

base 

400H, 

rfmsb 

equ 

base 

40EH 

rf  Isb 

equ 

base 

♦ 

40FH 

gate  array  <ga)  control  rgtr 
ga  atatus  rag! star 
IntarruptAINA  cnfgrtn  rgtr 
DMA  addrass  ragistar  hi 
DMA  addraas  ragistar  lo 
vector  pointer  rgtr  H2 
vector  pointer  rgtr  Hi 
vector  pointer  rgtr  #0 
register  file  access  hi 
register  file  access  to 


;•  Ethernet  <3coei)  Initialization  Values  • 

t 


eth_enable_reset 

ecAJ 

03h 

eth_di sable^reset 

equ 

OOh 

eth_acces8_prom 

04h 

eth_reev_select  , 

ecAi 

OOh 

eth_lan_conf ig 

equ 

49h 

eth_rem_OMA_burst 

e<^i 

08h 

eth_irq_line 

equ 

80h 

eth_rem_0MA_conf i g 

equ 

20h 

eth__xmi  t^buf  _start 

equ 

20h 

eth^recv_buf_start 

equ 

26h 

eth_fecvjjuf^end 

equ 

40h 

eth^offset 

eqM 

2000h 

eth_recv_begin 

600h 

eth_recv_end 

e<Ai 

ZQQOh 

eth_start_nic 

02h 

eth_nic_stop 

equ 

Olh 

eth_ni c_DMA_conf i g 

equ 

48h 

eth_remot e_?MA_ 1 0 

equ 

OOh 

eth_remote_DMA_h i 

equ 

OOh 

eth_packet_types 

equ 

Ofh 

eth_nic_mc!de 

equ 

02h 

eth_bndy_start 

e«AJ 

OOh 

eth_int^statU8 

equ 

Offh 

eth_i nts_enabled 

equ 

OOh 

eth_acce88_page_0 

e«AJ 

OOh 

eth_8cces8_page_1 

e<^ 

40H 

eth_exi t_mode 

e<w 

OOh 

nic_pr» 

e«h» 

1 

nic_ptx 

equ 

2 

send 

e«^ 

4 

;  Interrupt  Controller  conmand 


;  enable  reset 
;  disable  reset 
;  access  prom  bytes 
;  select  external  Xceiver 
;  8k  of  inem>aMp  I/O,  u/interrt4>ts 
;  #  of  bytes  to  transfer  on  DMA  burst 
;  interrupts  occur  on  IkOS 
;  8k  configuration  for  remote  DMA 
;  begin  of  transmission  buffer  (OH) 

;  receive  queue  (0600H) 

;  20  pages,  256  bytes/page  (2000H) 

;  difference  between  page  t  address 
;  actual  offset  in  RAM  seg  for  begin 
;  actual  offset  in  RAM  seg  for  end 
;  start  NIC 
;  stop  the  NIC 

;  local  DMA  operations,  8  byte  bursts 
;  DMA  remote  unused  (lo) 

;  DMA  remote  lasjsed  (hi) 

;  receive  any  kind  of  packet 
;  internal  loopback  mode 
;  FOR  NOW,  DO  NOT  USE  BOUNDRY  REGI 
;  Clear  status  of  all  ints  at  start 
;  enable  no  interrupts 
;  access  page  0  again 
;  access  NIC  page  1  registers 
;  exit  internal  loopback  mode 

;  mask  for  packet  receive  interrupt 
;  mask  for  packet  transmit  interrupt 

;  conmand  byte  to  start  transmission 
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NET_EOI  aqu  60N  *  vector_nkjnber  ;  -•  End  Of  lntern4>t  (specific) 

;  Ethernet  controller  routine  specifications 

;  Ethnct_Init  initializes  a  3com  Etherlink  II  board  to  transaiit  and  receive 
;  packets  via  a  aenory  napped  interface  with  the  board  located  at  OCOOtOOOO. 
;  The  base  address  from  which  the  registers  are  located  is  31Qh.  The  init 
;  routine  intializes  the  memory  to  zeroes  before  it  completes.  Although  no 
;  DMA  is  used  to  transfer  the  data  from  main  memory  to  the  board's  memory 
;  (which  is  referred  as  remote  DMA  operations),  there  is  no  choice  but  to 
;  use  the  local  DMA  operations  (trsnsferring  bytes  or  words  from  the  board's 
;  memory  to  the  board's  output  fifo's). 

•  LIST 
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page  55,132 

TITLE  10  *  Distributed  Ada  NettMrk  10 


;  FILE:  OA.IO.ASM 

;  10  MODULE  -  Low  Level  Network  Functions 

« 

Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
;  Derivation  :  LabTek  Distributed  Ada  VI. 0 
# 

;  This  Distributed  Ada  Runtime  inherits  the  LabTek  copyri^t. 

;  The  following  copyright  must  be  included  in  all  software 
;  utilizing  this  Ada  Runtime. 

» 

;  Copyright  1989  by  LabTek  Corporation,  Uoodbridge,  CT,  USA 

;  Permission  to  use,  copy,  modify,  and  distribute  this 
;  software  and  its  doctanentation  for  any  purpose  and  without 
;  fee  is  hereby  granted,  provided  that  the  above  copyright 

;  notice  appear  in  all  copies  and  that  both  that  copyright 

;  notice  and  this  permission  notice  appear  in  supporting 
;  docunentation,  and  that  the  name  of  LabTek  not  be  used  in 

;  advertising  or  publicity  pertaining  to  distribution  of  the 

;  software  without  specific,  written  prior  permission. 

;  Labfck  makos  no  representations  about  the  suitability  of 
i  this  software  for  any  purpose.  It  is  provided  "as  is" 

;  without  express  or  inplied  warranty. 

$ 

i:;;;;;;; Disclaimer 
/ 

;  This  software  and  its  docunentation  are  provided  "AS  IS"  and 
;  without  any  expressed  or  implied  warranties  whatsoever. 

;  No  warranties  as  to  performartce,  merchantability,  or  fitness 
;  for  a  particular  purpose  exist. 

0 

;  In  no  event  shall  any  person  or  organization  of  people  be 
;  held  responsible  for  any  direct,  indirect,  consequential 
;  or  inconsequential  damages  or  lost  profits.' 

0 

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  end - prologue  ; ; ; ; ; ; ; ; ; ; : ; ; ; ; ; ; ; ; ; ; ; ; ; 


The  10  module  provides  the  low_level  interface  to  the  network 
hardware  and  receive  message  buffering. 

This  code  is  loaded  into  all  processors,  and  adapts  to  the 
the  network  hardware  in  its  host.  Which  routines  are  used  is 
determined  solely  by  the  calls  made  from  the  application  code 
and  the  messages  received. 

The  10  interface  is  implemented  as  four  separata  functions: 
Initialize 
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Transmit  ; 

Racaiva  >  ; 

Interrupt  Procesing  ; 

f 

The  initialize  fuKtion  obviously  must  be  called  prior  to  any  ; 
other,  and  establishes  the  internet  vector  and  enables,  as  ; 

uell  as  prepares  the  hardware  for  use.  It  is  also  responsible  ; 
for  initilizing  data  structures  used  to  buffer  incoming  packets.  ; 

$ 

The  Transmit  function  is  used  by  one  task  at  a  time,  and  is  ; 

guarded  by  a  semaphore  to  provide  mutual  exclusion.  Once  the  ; 
transmit  resource  is  granted,  the  data  is  copied  into  the  on-card; 
buffer  and  sent  out  via  hardware  coamands.  (Mormally,  hardware  ; 
packet  acknowledge  should  be  provided  and  therefore  it  is  not  ; 
implemented  in  software,  even  though  Ethernet  does  not  support  ; 
hardware  acknowledge.)  ; 

The  Receive  function  is  provided  to  assist  in  transferring  the  ; 
data  to  the  requested  destination.  ; 

$ 

The  Interrupt  Processing  handles  both  transmit  complete  and  ; 

reception  interrupts.  For  transmit  complete,  the  resource  is  ; 

simply  made  available  again  by  performing  a  V  operation  on  the  ; 

trasmit  semaphore.  For  Receive  interrupts,  a  buffer  is  allocated; 
from  a  linked  list  of  fixed  sized  buffers.  Then  the  incoming  ; 

data  is  copied  to  the  buffer  and  the  distributed  rvntime  is  ; 

invoked  to  process  the  request.  It  may  simply  post  the  fact  the  ; 
message  has  arrived  (and  queue  to  an  entry),  or  it  may  cause  a  ; 
task  to  resvme  which  involves  signalling  (V  •  operation)  the  ; 
suspended  task.  )■ 

$ 

Refer  to  individual  procedure  headers  for  parameter  information  ; 
and  calling  requirements.  ; 


Ver  Date  Description 
0.1  Nov*88  :  Initial  prototype 


.model  large 

include  OA.DEF.ASN  ;  eontaina  software  definitions 

include  DA_HV.ASM  ;  contains  hardware  specifics 

public  IO_Mctwork_Init,  IO_Xmit 

public  TX_REAOT  ;  samaphore 

public  lO.ALLOCATE,  I0_DEALL0(JiTE 
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extrn 

VRTIF_Signal_I ;far 

;  signal  semaphore 

extrn 

VRTIf_Wait:far 

;  wait  on  semaphore  "P" 

extrn 

VRTlFJ8259:abs 

;  address  of  8259 

extrn 

VRT I F_vector_base : abs 

;  base  of  vector  table 

extrn 

Setup: near 

;  Initialize  Network  I/F 

extrn 

NET_Receive;near 

software  support  buffers 


« 

buff_size 

equ  2048  ;  bytes 

in  local  buffer 

n'jn_buff 

equ  20  ;  number 

of  buffers 

cseg  segment 

coamon 

org 

OCOOH 

assune 

cs : cseg , ds : cseg . es : cseg , $s : sseg 

;  NETWORK_INir  :  load  Interrupt  Vector  artd  clear  pointers  ; 


IO_Network_Init; 


push 

ax 

push 

bx 

push 

cx 

push 

dx 

push 

ds 

Do  low  level  Network  Interface  Card  Initialization 
call  Setup 
init  network  variables 


mov  ax ,  cs 

mov  ds,ax 

mov  tRECEIVE_PTRl ,eth_reev_begin  ;  receive  pointer 


Initialize  Receive  buffer  list 


lea 

ax,RX_BUFF_Q 

mov 

rRX_BUFF_HEADJ 

,ax 

lea 

sx.KX^BUfFEK 

P 

mov 

cx,ntiii_buff 

# 

lea 

bx,RX_BUFF_Q 

mov 

tbxl.ax 

« 

lea 

dx,  CbxH] 

• 

mov 

Cbx'»2]  ,dx 

9 

add 

ax,buff_size 

« 

points  to  actual  buffers 
nuitier  to  link 

points  to  buffer  descriptors 

put  in  current  buffer  pointer 
OX  is  address  of  next  descriptor 
put  it  in  as  next  pointer 
point  AX  at  next  buffer 
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MOV 

loop 
now  fix  up 

MOV 


bx,dx  ;  change  descriptor  pointer  to  next 

InitJO 

last  pointer 

word  ptr  [bx*2],0  ;  tenainate  list 


load  interrupt  vector 

MOV  ax,0 

MOV  ds,ax 

MOV  bx,VRTIF_vector_base*<vector_ni«ter*4) 

MOV  ax, offset  Interrupt^Handler 

MOV  Ibx],ax 

MOV  ax,cs 

MOV  tbx^Zl.ax 

Note:  Preliminary  board  initialization  was  done  in  SETUP  code,  now 
just  enable  interrupts 


MOV 

dx.VRTIFjaaSO^I 

in 

al,dx 

;  get  interrupt  mask 

mov 

ah, Of EH 

;  mask  to  clear  zero  bit 

fMV 

cl,veetor_no«fcer 

;  load  shift  count  register 

rol 

ah, cl 

and 

al,ah 

;  enable  level 

out 

dx,al 

;  update  controller  chip 

MOV 

dx,cntrl 

mov 

a 1 , eth_access j>age_1 

;  access  NIC  page  1  registers 

out 

dx,al 

mov 

dx,nic_iBr 

;  interrupt  mask  register 

mov 

al  ,nic_prx'rnic_ptx 

;  enable  xmit/recv  interrupts 

out 

dx,al 

pop 

ds 

pop 

dx 

pop 

cx 

pop 

bx 

pop 

ax 

rtt 

beader_size  equ  10  ;words;dst»3,src»3,RCP*1,priority*1,saq»1,len9th«1 


XMIT  ■  transMit  the  message  specified  by  paraMeter  list 
starting  at  address  is  at  8S:bp*OEF_TCP 
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INPUTS: 

TRANSMIT  CONTROL  POINTER 

Nunber  of  parameters 

offset 1 

segment 1 

lengthi 

lO.Xmit: 

...  etc. 

push 

cs 

push  segment  ef  transmit  Ctrl  seawphore 

lea 

ox,TX_READY 

push 

ax 

push  offset  of  senmphore 

call 

VRTIF_Wait 

do  p  semaphore  operation 

;  put  header 

in  packet  buffer 

mov 

si , tbp*OEF_TCP] 

fetch  Transmit  control  pointer 

les 

di. [CARO.RAM] 

point  to  hardware  buffer  area 

mov 

cx,header_size 

in  words 

mov 

.lPAaCET_SIZE]  ,cx 

initialize  packet  size  (in  words) 

sub 

pushf 

cU 

cx,2 

do  not  copy  sequence  and  length  fields 

repz 

popf 

movsu 

• 

;  Update  Sequence  Nunber  and  put  it 

in  packet 

1 

mov 

si.Csi]  ;  fetch  sequence  offset 

mov 

ax,  [si]  ;  get  sequence  count 

inc 

ax 

stosw 

;  put  sequence  count  in  packet 

mov 

Csil.ax  ;  update  counter  ; 

;  skip  over 

length  field  for  now 

! 

add 

di,2 

t 

;  <.opy  the  parameters  into  the  packet  buffer 

! 

mov 

si  ,OEF_Parameters 

;  offset  from  BP  to  parameter  list 

mov 

cx,  Cbprsi-rOEF_param_eount]  ;  nunber  of  parameters 

jexz 

Xmit_20 

;  if  no  parameters 

add 

XmitJO: 

si, 2 

;  increment  to  actual  parameter  info 

push 

cx 

mov 

cx, tbp»ai+OEF_param_length] ;  get  size  of  parameter  (bytes) 

shr 

cx,1 

;  convert  to  words 

add 

tPACKET_SIZE] ,cx 

;  accuaulate  into  packet  size  coulter 

push 

ds 

Ids 

si,  tbp*si*OEF_PARAM_^OFFSET] ;  get  address  of  parameter 

rep 

movaw 

;  copy  data  to  pocket  buffer 

pop 

dt 
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add  si,06F_parM_descrfptor  ;  90  to  next  poraMter  descriptor 

pop  cx  ;  gat  paramOtar  count  back 

loop  Xmit_10 

Mow  all  paramatars  have  been  copied  in,  now  insert  length  field 


Xmit  20: 


les 

add 

mov 

stosu 

di ,  CCARO.RAMI 
di ,data_length 
ax,  [PAC«T_S1ZE] 

;  point  to  hardware  buffer  area 
;  add  offset  to  data  length  field 

;  stick  in  PACKET  length 

Setup  NIC  registers  to  begin  transmission 

Must  prevent 

a  RECEIVE  interrupt  from  arriving,  which  would  Interfere 

with  the  registers  being  updated  for 

Transmission. 

load  start  address  of  packet 

pushf 

;  save  interrupt  status 

cli 

;  disable  any  interrupts 

mov 

dx,nic_cr 

;  select  Page_0 

mov 

a 1 , eth_aecess_Page_0 

out 

dx,al 

mov 

dx,nic_tpsr 

;  page  start  register 

mov 

a 1 , eth_xmi t_buf _8tart 

;  transmit  page  at  0C00:0000 

out 

dx,al 

load  length 

of  packet 

mov 

ax, CPACKET_SI2E] 

shl 

ax,1 

;  convert  word  to  byte  count 

mov 

dx,nic_tbcrO 

out 

dx,al 

mov 

dx,nic_tbcr1 

mov 

al,ah 

out 

dx,al 

start  transmit 

mov 

dx,nlc_cr 

mov 

al,send  ;  comnand  to  initiate  transmission 

out 

dx,al 

popf  ;  restore  interrupt  status 

ret 


INTERRUPT  SERVICE  ROUTINE 


Currently,  this  must  have  a  stack  fraiae  similar  to  other  vendor 
interrupt  routines  so  that  the  interrupt 'mode  Signal  routine  will 
be  able  to  find  the  interrupt  return  address  and  status 
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Interrupt^Handler  label  far 


push 

bp 

mov 

bp,sp 

push 

ax 

push 

bx 

push 

cx 

push 

dx 

push 

si 

push 

d1 

push 

ds 

push 

es 

Setup  data  segment 

mov 

ax,seg  cseg 

mov 

ds,ax 

First  fetch  rnterrvB>t  status. 

and  clear  interrupt  request 

mov 

dx,nic_cr 

;  select  Page^O 

mov 

al ,eth_access_Page_0 

out 

dx,al 

mov 

d*,nic_isr 

;  look  at  interrupt  status  register 

in 

al,dx 

mov 

CISRl.ax 

;  save  status 

out 

dx,al 

;  clear  interrupts 

Clear  the  8259  Interrupt  Request 

mov 

al,NET_EOI 

;  issue  EOl  to  interrupt  controller 

mov 

dx,VRTIFJ8259 

out 

dx,al 

check  for 

receive  interrupt 

test 

[ISR]  ,nic_prx 

;  see  if  receive  interrupt 

jz 

Check_Xmi t 

;  Receive  conplete  interrupt,  process  incoming  packet 
;  NOTE:  since  this  is  done  inside  the  interrupt  routine,  interrupts 
;  are  disabled,  and  therefore  there  is  no  interference  from  possible 
;  receive  interrupts. 

Receive: 

;  Allocate  a  buffer,  and  transfer  data  to  the  buffer 

;  after  the  fol lowing  call,  the  buffer  descriptor  is  in  BX.  DO  NOT  DESTROY  BXt 
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call  I0_A1 locate 

MOV  ax,cs  destination  segment  is  CS 

mov  es,ax 

nov  di.Cbx]  ;  destination  offset  is  buffer  at  BX 

Ids  si ,  tCMO.RAM]  ;  source  is  ethemet  RAM 

add  si,cs:tRECEIVE_PTR];  add  current  receive  buffer  page  address 
lodsw  ;  fetch  status  into  AL,  NEXT  PTR  into  AH 

xor  al,sl  ;  zero  low  byte,  leaving  a  new  pointer 

sub  ax.eth^offset  ;  correct  for  mesnry  vs  page  offset 

mov  cs: CRECEIVE_PTR] ,ax;  get  ready  for  next  reception 

add  si, 2  ;  skip  over  receive  byte  count 

;  SI  now  points  to  first  part  of  transmitted  packet 

mov  ax, [si^data^length]  ;  get  size  of  valid  packet  in  WORDS 


Now  transfer  memory  from  hardware  buffer  pages  to  software  buffer. 
Note  that  the  buffer  will  wrap  aroiaid  at  4000H  back  to  2600. 


RECV010: 


RECV020: 


RECV030 


RECV040: 


mov 

dx,80H-2 

;  page  size  in  words  (reduced  to  get 

Clip 

ex,dx 

;  see  if  more  than  a  page 

jae 

RECV020 

mov 

dx,ax 

;  otherwize  only  move  the  remaining 

mov 

cx,dx 

rep 

movsw 

;  do  the  transfer 

onp 

si,eth_recv_end 

;  see  if  at  end  of  hardware  buffer 

inz 

RECV030 

mov 

si ,eth_recv_begin;  reset  pointer  to  begin 

sub 

8x,dx 

;  reduce  total  count  by  those  moved 

jz 

RECV040 

;  finished  if  so 

mov 

dx,80H 

;  keep  page  alignment 

imp 

RECV010 

mov 

ax,cs 

;  restore  data  segment 

mov 

ds,ax 

Call  Receive  portion  of  Distributed  Runtime  code  to  determine 
tN)at  should  be  done  with  the  newly  arrived  packet. 

call  NET_Receive 

Check  to  see  if  any  more  work  to  do,  if  so  then  skip  clearing 
the  interrupt  so  that  another  interrupt  will  occur  imediately 
upon  enabling  interrupts  (possibly  after  a  trip  through  the 
scheduler). 

Note  that  a  limitation  in  the  Ethernet  hardware  results  in 
a  possible  race  condition  here. 


cli  ;  reduce  chance  of  race  (in  case  VRT  enabled) 

mov  dx,nic_cr 


-196- 


Demonstration  Project  Final  Report 


nov 

al,eth_access_Page_1  ;  select  page  r 

out 

dx,al 

nov 

dx,nic_curr  ; 

get  current  page  register 

in 

al,dx 

fetch  current  page  register 

nov 

ah,al  ; 

build  memory  address 

xor 

al,al 

sub 

ax,eth_offset  ; 

correct  for  NIC  displaccaient 

cnp 

ax, tRECEIVE.PTRl; 

check  if  our  pointer  is  the  same 

jz 

Checkjlmi  t  ; 

if  no  uork,  don't  print  notice 

i 

this  will  result  in  an  inaediate  re-interrupt 

§ 

as  soon  as  interrupts  are  enabled 

• 

(which  mer,ns  after  scheduling  event) 

Nou  check 

for  transmit  complete  interrupt 

Check^Xmit: 

* 

test 

IlSR3,nic_ptx  ; 

check  for  packet  transmitted 

jz 

EOt 

$ 

;  Transmit  complete,  first  clear 

interrupt  request,  then  signal  semaphore 

t 

Transmit; 

push 

cs  ; 

segment  of  semaphore 

lea 

ax,  TX  .READY 

offset  of  semaphore 

push 

ax 

call 

VRTIF_Signal_l  ; 

signal  completion 

EOI: 

pop 

es 

pop 

ds 

pop 

di 

pop 

si 

pop 

dx 

pop 

cx 

pop 

bx 

pop 

ax 

pop 

bp 

iret 

IO_ALLOCATE  *  Allocates  next  tsuffer  from  Avail  list 
Return  BX  pointing  to  buffer  queue  index. 

By  design,  the  buffer  should  queue  should  never  be  enpty. 
Destroys  AX  ,  BX  has  ncM  descriptor  pointer 


IO_ALLOCATE; 
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cli 

MOV 

bx, [RX_BUFF_HEAD1 

;  fetch  head  pointer 

or 

bx,bx 

;  see  if  empty 

Jnx 

IO_ALLOC10 

:  go  on  if  not 

Mornwlly,  might  raise  storage  error  here,  but  design  prevents 
exceeding  buffer  cepacity  mless  there  is  some  code  flaw. 

popf 

int  3  ;  trap 


Remove  buffer  descriptor  from  free  list 


lO^ALLOCIO: 

mov 

ax,  Cbx-»OEF_HEXT_PTR] 

;  fetch  next  pointer 

<nv 

CRX^BUFF.HEADl ,ax 

;  pull  buffer  off  list,  replace  head 

xor 

ax, ax 

;  null  next  pointer  in  buffer 

mov 

tbx-K)EF_NEXT_PTRl  ,ax 

popf 

rot 

lO^DEALLOCATE  •  Deallocates  buffer  into  Avail  list 
Takes  BX  pointing  to  buffer  descriptor. 

By  design,  the  buffer  should  queue  should  never  be  full. 
Destroys  AX 


I 0_DEAL LOCATE: 


pushf 

cli 

mov 

ox, tRX_BUFF_HEADl 

;  get  heed  of  list 

RIOV 

Cbx+DEF_MEXT_PTRJ ,ax 

;  put  behind  this  entry 

mov 

popf 

ret 

CRX_BUFF_HEADI ,bx 

;  make  this  entry  new  head 

Data  AREA 


0 

align 

4 

ISR 

dM 

0 

;  interri^t  status  register 

PACKET_SI2E 

du 

0 

;  packet  size 

BUFFER  QUEUE  STRUCTURE 
record 

BUFFER.OFFSET 
REXT.PTR 
end  record; 
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CARD_RAM  dd  OdcOOOOOOh  ;  address  of  ra«  buffer  on  cnet  card 

RECE1VE_PIR  du  7  ;  points  to  current  next  page  to  rev 


The  foUouing  seoiaphore  is  used  to  provide  flutuat  exclusion  to  the 
transmit  side  of  the  Ethernet  card. 


TX  READY 


dw  1 

du  0 

du  0 


;  semaphore  covit 
;  task  value 
;  task  value 


RX_8U.*F_HEAD  du 
RX_iiUfFER  db 
RX  BUFF  Q  du 


(?) 

nimi_buff  dup  (buff^size  dup  (?)) 

nui_buff  dup  (2  dup<?))  ;  (BOFFER_PTR,  IIEXT_DESC_PTR> 


cseg  ends 


sseg  segment  STACK 

du  100  dup  (0) 
sseo  ends 

end 
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page  55.132 

TITLE  LINK  •  Ofstributed  Ada  Linkage  Nodufe 


FILE:  OA.LINK.ASN 

LINK  •  Distributed  Ada  ■  Linkage  Module 

Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
Derivation  :  LabTek  Distributed  Ada  VI. 0 

This  Distributed  Ada  Riaitime  inherits  the  LabTek  copyright. 
The  following  copyright  isust  be  included  in  all  software 
utilizing  this  Ada  Runtime. 

Copyright  1989  by  LabTek  Corporation.  Uoodbridge.  CT.  USA 

Permission  to  use.  copy,  modify,  and  distribute  this 
software  and  its  docunentation  for  any  purpose  and  without 
fee  is  hereby  granted,  provided  that  the  above  copyright 
notice  appear  in  all  copies  and  that  both  that  copyright 
notice  and  this  permission  notice  appear  in  supporting 
docvjnentation.  and  that  the  name  of  LabTek  not  be  used  in 
advertising  or  pkAlicity  pertaining  to  distribution  of  the 
software  without  specific,  written  prior  permission. 

LabTek  makes  no  representations  about  the  suitability  of 
this  software  for  any  purpose.  It  is  provided  "ss  is" 
without  express  or  implied  warranty. 

ttfSitiitStttifitt  Disclai mar 

This  software  and  its  docunentation  are  provided  "AS  IS"  and 
without  any  expressed  or  implied  warranties  whatsoever. 

No  warranties  as  to  performance,  merchantability,  or  fitness 
for  a  particular  purpose  exist. 

In  no  evant  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damages  or  lost  profits. 

; ; ; ; ; ; ; ; ; ; ;; ; ; ; ; ; ;  end-prolocue  ; ; ; ; ; ; ; ; ; ; ; ; ; ; .- ; ; ; ; ; 


This  code  is  code  that  would  be  generated  by  the  Compiler /Linker 
and  Distributor.  It  is  kept  separate  from  the  runtime  "routines" 
to  delineate  the  generated/naftima  boundry. 

This  coda  is  Linked  to  the  Ada  application  via  (hand)  editing 
of  runtime  calls  within  the  generated  Ada  program.  Esaantially, 
a  call  is  made  from  each  of  the  rendezvous  operations  in  the 
generated  call  to  the  respective  support  code  here,  then  a  return 
is  made  back.  Since  the  compiler  does  not  supply  information 
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on  the  parameters  fn  the  code  (<t  Is  Implicitly  melnteined  by 
the  compiler  amoung  entry  call/accept  pairs),  a  Tittle  at^port 
code  is  placed  here  to  provide  the  information.  Normally  a 
compiler  that  si^ports  distribution  would  put  this  in  line. 

The  support  code  then  calls  general  purpose  (although  prototype) 
routines  to  implement  remote  entry,  accept,  select,  and  error 
OHchanisais. 

Each  packet  header  is  statically  formed  and  placed  in  this 
module  to  be  reference  by  the  TRANSMIT  CONTROL  PTR  (TCP)  used  in 
the  runtime  call  parameter  list.  This  redtjces  the  overhead 
associated  with  packetizi;ig  the  data.  These  packet  headers 
could  be  generated  by  the  compiler/l inker/distributor  and 
optimally  would  be  placed  in  the  controller  card  memory  at 
elaboration  time  so  that  loading  of  header  data  would  be 
necessary. 


Ver  Date  Description 
0.1  Nov>88  ;  Initial  prototype 


include  OA^OEF.ASM 

.model  large 

extrn  Initialize:far 

extrn  remote_entry;far,  local_entry;far 

extrn  Any_select:far,  remote_accept:far,  remote_end_accept:far 
extrn  local_end_accept:far 

extrn  remote_elab_start:far,  remote_elab_wait:far 
extrn  remote_elab_continue:far 
extrn  IO_DEALLOCATE:near 
extrn  outehr:near 

cseg  segment  common 


Lengths  of  rendezvous  data  parameters 


ROCKET_MSO_TYPE_LEMCTH 

equ 

202 

ROCkET.GU I 0E_MSG_T YPE.LENGTH 

equ 

122 

TARGET_MSG_TYP6_LENGTH 

•qu 

1002 

Rendezvous  parameter  offsets 
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MEXT_ROaCET_MSG 

•qu 

1908 

offset 

froai 

BP 

CONTROL.GUIDE.MSG 

equ 

386 

• 

offset 

froa 

BP 

ROCXSUR.GUIDE.NSG 

•qu 

-334 

« 

offset 

froai 

BP 

ROCKSUI»_REPORT_MSG 

•qu 

-212 

« 

offset 

froai 

BP 

TAR6ET_MSG 

-1012 

$ 

offset 

froai 

BP 

•ssune  cs:cseg,ds:cse9,es:cseg 


The  following  juqp  table  provides  (static)  control  transfers  froai  the 
Ada  application  code  to  the  respective  support  code  located  here 


• 

align  8 

jap 

Init 

;  prior  to  elaboration 

align  8 

jmp 

Elaborate.Start 

;  to  synchronize  elaboration 

align  8 

jqp 

Elaborate_Wait 

;  will  wait  for  elaborate  sync. 

align  8 

jiap 

E 1  aborate_Cont  i  nue 

;  to  acknowledge  completion 

align  8 

jwp 

get_report_entry 
align  8 

;  called  by  Rocket. Control 

j"P 

put_report^ent  ry 
align  8 

;  called  by  Simulate.ROL.Rocket_Support 

jiap 

report_buf^seleet 
align  8 

;  called  by  Simulate. R0L.Report_Buf 

jmp 

get_report_end_accept 
align  8 

;  called  by  Simulate.RDL.Report_Buf 

imp 

put_report_end_accept 

;  called  by  Simulate.ROL.Report.Buf 

align  8 

lap 

8^t_guide_entry 
align  8 

;  called  by  Simulste.ROL.Rocket^Support 

jmp 

gu i de_buf _se 1 ect 
align  8 

;  called  by  Simulate. RDL.GuideJiuf 

jmp 

put_guide_entry 

;  called  by  Rocket. Control 

align  8 

jmp 

Bet_next_target_entry 
align  8 

;  called  by  Target. Track 

jmp 

get_next_target_accept 
align  8 

;  called  by  Sliisi(ate.Sensor.Targ_Support 

jmp 

gct_next_targct_end_accept;  called  by  Simulste.$ensor.Targ_Support 

align  8 

jap 

get_guide_end.accapt 

;  called  by  Simulste.ROL.Guidebuf 
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align  8 

jnp  put_guide^end_accept  ;  called  by  SiRulate.ROL.Suldabuf 
align  BOH 


;  INIT  to  initialize  the  network  hardware 
0 

Init: 


push 

ds 

mov 

ax,cs 

mov 

dSfSX 

call 

tnitlaUze 

pop 

ds 

retf 

;  ELABOBATE.START 

;  The  main  prograa  calls  this  routine  to  send  a  "start"  to  the 
;  bravo  processor.  The  ren»te_elab_start  routine  wilt  suspend 
;  the  mein  program  until  the  continue  is  received  from  the 
;  elaborating  processor. 

# 

£laborate_Sfart: 


push 

ds 

mov 

%X,C8 

mov 

ds,ax 

xor 

ax, ax 

0 

no  parameters 

push 

ax 

lea 

ax , TX_e 1 aborate_beg i n 

0 

transmit  control  ptr 

push 

ax 

lea 

ax,Nain_TCB 

0 

task_id 

push 

ax 

call 

remote_elab_start 

add 

sp,6 

0 

fix  up  stack 

Normally,  test  AX  for  NZ  to  see  if  there  was  an  elaboration 
error  on  the  ra>x>te  processor,  however  it  will  be  ignored 
in  this  case. 

pop  ds 
retf 


;  ELABORATE.UAIT  :  Suspends  a  task  until  it  is  given  the  signal 
;  to  continue  from  the  elaborating  processor. 

Elaborate_Wait: 

push  ds 

mov  ax,cs 
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mov 

ds,ax 

lea 

ax,Ma1n_TCB.EMTRTl,0 

;  put  main  entry  queue  (pseudo) 

push 

ax 

lea 

ax,Main_TCB 

push 

ax  ;  put 

main  TC8  as  task.ld 

call 

remote_elab_wa1t 

add 

sp,* 

pop 

ds 

retf 

:  ELABORATE_CONTINUE  :  Not<f)M  th*  •laborating  processor  that 

;  the  specified  elaboration  In  complete  and 

;  that  It  can  continue  elaboration  of  other 

;  units. 

E  laborate_Cont  1  nue: 
push  ds 

■ov  ax,cs 

■ov  ds.ax 

xor  ax, ax  ;  no  parameters 

push  ax 

lea  ax,Ma1n_TC8.ENTRTl_Q  ;  pass  entry  queue  in  place  of  TCP 

push  ax  ;  KTS  will  deallocate  incoming  buffer 

lea  ax.Maln.TCB  ;  and  calling  task  Id 

push  ax 

call  rcMote_elab_cantinue 

add  sp,6  ;  remove  parameters 

pop  ds 

retf 


;  GET_I1EPCIRT_EMTRY 
« 

get_report_entry:  ;  called  by  Rocket. Control 


push 

ds 

mov 

ax,cs 

mov 

ds,ax 

mov 

al.'R' 

call 

outchr 

mov 

al.'O' 

call 

outchr 

mov 

el.'  ' 

call 

outchr 

Push  parame 

ters  for 

remote  rendezvous  entry 

xor 

ax, ax 

;  no  IN  parameters,  set 

count  to 

zero 

push 

ax 

laa 

ox,TX_raport_beg1n_entry  ; 

transmit 

control  ptr 
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push  ax 

lea  ax,Control_TCB  ;  rocket .control  task 

push  ax  ;  push  task_id 

call  re(iiote_entry 

add  sp,6  ;  clean  up  stack 

nov  bx.uord  ptr  [Control_TCB-H3EF_TCB_REPLY]  ;  jet  reply  pointer 

Copy  out  parameter,  (BX)  points  to  buffer  descriptor 

lea  di , tbp+NEXT_ROCXET_hSG] 

flov  si.lbx] 

lea  si , Csi^data.field] 

IBOV  cx,ROCICET_MSC_TYPE_LEHCTH 

shr  cx,1 

a»v  ax,ss 

nov  es.ax 

pushf 
cli 

rep  movsu 

popf 

call  10_0eal locate  ;  Deallocate  receive  buffer 

pop  ds 

retf 


;  point  to  MEXT_ROCKET_MSG 

;  get  address  of  buffer 

;  get  pointer  to  data  in  packet  buff 

:  word  count 


;  NOTE:  STACK  FRAME  LOCATIONS  ARE  POSITION  DEPENDENT 
report_buf_seleet:  ;  called  by  Simulate.ROL.Report_Buf 


push 

ds 

mov 

ax.cs 

fflOV 

ds,ax 

mov 

al.'R' 

call 

outchr 

mov 

al.'s' 

call 

outchr 

mov 

si,'  ' 

call 

outchr 

lea 

ax , Reportbuf _TC8 .ENTRT1_Q 

;  get  report 

push 

ax 

lea 

ax , Reportbuf _TCB . ENTRY2_Q 

;  put  report 

push 

ax 

mov 

ax, 2  ; 

muter  of  entries  (fixed) 

push 

ax 

lea 

ax, Reportbuf _TCB  ; 

task_id 

push 

ax 

call 

Any_select  ; 

parameter  pointer  t  selector  on  stack 

add 

sp.B 

restore  stack 
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;  place  return  paranieters  on  atack 


push  bp 

■ov  bp.sp 

■ov  [bp*81,ax 

MOV  [bp»10l,bx 

a»v  ax.cs 

«ov  [bp*'12l,ax 

pop  bp 

pop  ds 

retf 


get_report_end_accept ;  ;  called  by  Simulate. ROL.Report_Buf 


push 

ds 

mov 

ax.cs 

siov 

ds.ax 

mov 

'al.'e' 

call 

outchr 

mov 

al.'A' 

call 

outchr 

mov 

al.'  ' 

call 

outchr 

RIOV 

ax , ROCKET_NSG_TYPE_LEMGTH 

9 

length 

push 

ax 

address 

of  data  buffer  on  stack  (first 

•nd 

only  parameter) 

push 

word  ptr  es:Cbx] 

« 

segment 

push 

word  ptr  es: tbxrZ] 

offset 

mov 

ax.l 

» 

rurber  of  out  parameters 

push 

ax 

lea 

ax,Reportbuf_TCB.EMTRYl_Q 

t 

entry_l0 

push 

ax 

lea 

ax,Reportbuf_TC8 

f 

task  id 

push 

ax 

call 

refflote_end_accept 

add 

sp,12 

$ 

remove  parameters  from  stack 

pop 

ds 

retf 

:  put  selector  on  stack 
;  put  offset  of  data  pointer  on  stack 

;  put  segment  of  data  pointer  on  stack 


put_report_end_accept :  ;  cal  lad  by  Simulate. ROL.Rcport_Buf 


push 

ds 

ROV 

ax.cs 

MOV 

ds.ax 

MOV 

al.'E' 

caU 

outchr 

MOV 

al.M' 

call 

outchr 
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iiov  al,'  ' 

call  outchr 

lea  ax,Reportbuf_TC8.ENTRY2_Q 

push  ax 

call  local_encl_accept 

add  sp,2  ;  ramova  parameter 

pop  ds 

retf 


;  NOTE:  THIS  IS  A  ENTRY  CALL  to  a  LOCAL  TASK) 

0 

put_raport_entry:  ;  called  by  Simulate. ROL.Rocket_Sopport 


push 

ds 

mov 

ax.cs 

snv 

ds.ax 

mov 

al.'R* 

call 

outchr 

mov 

al.'P' 

call 

outchr 

mov 

•  1,'  ' 

call 

outchr 

push 

ss 

$ 

segment  of  data 

lea 

ax, Cbp*ROCKSUP_REPORT_NSG] 

$ 

offset  of  data 

push 

ax 

lea 

ax , Reportbuf _TC8 . ENTRY2_0 

0 

dst  entry  ID 

push 

ax 

lea 

ax,Reportbuf_TCB 

0 

dst  task  id 

push 

ax 

lea 

ax,Rocksup_TCB 

0 

src  task  id 

push 

ax 

call 

local_entry 

add 

sp,10 

0 

restore  stack 

pop 

ds 

retf 

;  called  by  Simulate. ROL.Rocket_Support 


get_gui de_ent ry : 


push 

ds 

mov 

ax,cs 

mov 

ds,ax 

mov 

al,'G' 

call 

outchr 

mov 

al.'E' 

call 

outchr 

mov 

al,'  ' 

call 

outchr 

push 

ss 

;  segment  of  data  area 
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lea 

ax,  Cbp*'ROCKSUP_GUIDE_HSGl 

;  offset  of  data 

push 

ax 

lea 

ax , Gui defauf _TCB . ENTRY 1_a 

;  dst  entry  ID 

push 

ax 

lea 

ax,Guidebuf_TCB 

;  dst  task  id 

push 

ax 

lea 

ax,Rocksup_TCB 

;  src  task  id 

push 

ax 

cal  1 

local_entry 

add 

sp.10 

;  restore  stack 

pop 

ds 

retf 

;  NOTE:  STACK  FRAME  LOCATIONS  ARE  POSITION  DEPENDENT 
guidk_buf_select:  ;  callad  by  Simulate. RDL.Guide_Buf 


push 

ds 

nov 

ax,cs 

mov 

ds,ax 

mov 

al.'G' 

call 

outchr 

mov 

al.'S' 

call 

outchr 

mov 

al.'  ' 

call 

outchr 

mov 

ax,1 

;  always  1  entry  (put.next) 

mov 

cx, tbp-1341 

;  check  MSC_C0UNT 

cmp 

cx,0 

jle 

gbslO 

;  if  guard  closed 

inc 

ax 

;  allow  two  entries 

lea 

bx.Guidebuf, 

,TC8.ENTRY1_0 

;  Get_next_9uide 

push 

bx 

;  put_next_guide  is  always  open 

gbslO: 

lea 

bx.Guidebuf^ 

,TCB.ENTRY2_0 

;  Put_next_guide 

push 

bx 

push 

ax 

• 

nunber  of  entries 

lea 

ax,Guidebuf, 

.TCB  ; 

task_id 

push 

ax 

call 

Any^select 

0 

parameter  pointer  t  selector  on  stack 

pop 

cx 

$ 

remove  task_id 

pop 

cx 

0 

get  number  of  entries 

shl 

cx,1 

0 

two  bytes  per  entry 

add 

sp,cx 

0 

remove  local  stack  frame 

place  return  parameters  on  stack 


0 

push 

tap 

mov 

bp.PP 

mov 

tfap*B],ax 

;  put  selector  on  stack 

mov 

tbpr10],bx 

;  put  offset  of  data  point) 
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mov  ax,cs 


MOV 

pop 

pop 

retf 

Cbp*12j,ax  ;  put  segment  of  data  pointer  on  stack 

bp 

ds 

get_guide_end_accept:  ;  called  by  Simulate. R0L.Gutde_Buf 

push 

ds 

mov 

ax,cs 

mov 

ds,ax 

mov 

al.'G' 

cal  1 

outchr 

mov 

al.'e' 

call 

outchr 

mov 

al.'  ' 

call 

outchr 

lea 

ax . Gui debuf_TCB . ENTRY 1 _Q 

push 

ax 

cat  1 

Loca l_End_Accept 

add 

sp,2  ;  remove  parameter 

pop 

retf 

ds 

put_guide_end_accept:  ;  called  by  Siinjlate.RDL.Gui'de_6vif 

push 

ds 

mov 

ax,c8 

mov 

dSyax 

mov 

al.'G' 

call 

outchr 

mov 

al,'p' 

cal  1 

outchr 

mov 

al,'  ' 

call 

outchr 

mov 

ax,0  ;  nunber  of  out  parameters 

push 

ax 

lea 

ax,GuidcbJf_TCB.EMTRY2_Q  ;  entry_ID 

push 

ax 

push 

ax  ;  leave  space  normally  task_  id 

call 

refflote_end_accept 

add 

sp,6  ;  remove  parameters  from  stack 

pop 

retf 

ds 

put_guide_antry:  ;  called  by  Rocket. Control 

push  ds 

MOV  ax,cs 

MOV  ds,ax 


-209. 


Demonstration  Project  Final  Report 


«ov 

al.'G' 

call 

outchr 

■ov 

al.'P' 

call 

Outchr 

■ov 

al,'  ' 

call 

Outchr 

■ov 

ax,  ROCICET_OJIOE_MSG_TYPE_LEMCTH 

• 

length 

push 

ax 

push 

as 

$ 

current  stack  segment 

lea 

ax. [bprCONTROL_GUIDE_NSGl 

» 

offset 

push 

ax 

■ov 

ax,1 

* 

1  in  parameter 

push 

ax 

lea 

ax , TX_gu i de_beg i n_en t  ry 

« 

tx  control  pointer 

push 

ax 

lea 

ax,Control_TCB 

i 

task  id 

push 

ax 

call 

reii»te_entry 

add 

sp,12 

$ 

restore  stack 

■ov 

bx.word  ptr  tControl_TCB>OEF_TCB_REPLtl 

t 

get  reply  pointer 

call 

I0_0eaUocate 

• 

§ 

no  OUT  entry  params 

pop 

ds 

retf 

get_n**t_targ«t_entry!  ;  called  by  Target. Track 
push  da 


fflov 

ax,cs 

mbv 

ds,ax 

inov 

al,'T' 

call 

outchr 

mov 

al.'G' 

call 

outchr 

mov 

•1.'  ' 

call 

outchr 

xor 

ax, ax 

;  no  in  parameters 

push 

ax 

lea 

ax,TX_track_begin_entry  ;  transmit  control  ptr 

push 

ax 

lea 

ax,Track_TCB 

;  t88k_id 

push 

ax 

call 

rewote_entry 

add 

sp,6 

;  clean  up  stack 

mov 

bx.Hord  ptr  tTrack_TCB+OEF_TCB_REPLTl  ;  get  reply  pointer 

Copy  out 

parameter,  (BX)  points 

to  buffer  descriptor.  01  to  control  block 

tea 

di , CbprTARGET.HSGl 

;  point  to  TARGET_NSG 

■ov 

si,  Cbx] 

;  get  actual  buffer  address 

lea 

si,  tsi'Tdata^field] 

;  point  to  packet  data 
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mov  cx,TARGET_MSG_TYPE_LEMGTH 

shr  ex,1  ;  make  wrd  count 

■ov  ax,ss 

mov  es,ax 

pushf 

cli 

rep  movsw 

pop# 

call  IO_Deal locate  ;  Deallocate  receive  buffer 

pop  da 

retf 


jet_next_tar9et_accept;  ;  called  by  Simulate. Sensor. Targ^Si^iport 


push 

ds 

mov 

ax.cs 

t»v 

ds,ax 

mov 

.al.'T' 

call 

outchr 

mov 

al.'a' 

call 

outchr 

mov 

al,'  ' 

call 

outchr 

lea 

ax,Targsup_TCB.EMTRY1_0 

;Entry  Queue  of  interest 

push 

ax 

lea 

ax,Targsup_TCB 

:  our  task^id 

push 

ax 

call 

remote.accept 

;  returns:  ES:BX*data  ptr 

add 

sp.4 

;  adjust  stack  back 

pop 

retf 

ds 

get_next^target_end_accept:  ;  called  by  Simulate. Sensor. Targ_Support 


push 

ds 

mov 

ax.cs 

mov 

ds.ax 

mov 

al.'T' 

call 

outchr 

mov 

al.'b' 

call 

outchr 

mov 

al.'  ' 

call 

outchr 

mov 

ax . TARGET_MSG_TYPE_LEHGTH 

push 

ax 

address 

of  data  buffer  on  stack  (first 

•nd 

only  paramater) 

push 

word  ptr  es: Cbx] 

f 

segmant 

push 

word  ptr  es:  [bx‘»2] 

$ 

offset 

mov 

ax.1 

i 

mMber  of  out  parameters 

push 

ax 
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lea 

ax , Targsup.TCB . ENTRY 1^0  ; 

entry^IO 

push 

ax 

- 

push 

ax  ; 

leave  space  nortaally  task,  id 

call 

rcmote^end.accapt 

add 

»P.12 

reiaove  parameters  from  stack 

pop 

ds 

retf 

align 

80H  ;  keep  addresses 

from  changing 

Packet  Header  Data,  pointed  to  by  the  TRANSMIT  CONTROL.PTR  (TCP) 

The  foUoMing  data  structures  are  used  to  generate  and  respond  to 
data  packets. 


type  TRANSMIT_CONTROL_TYPE  is  record 


DESTINATION 

SOURCE 

RCP 

PRIORITY 
SEQUENCE.PTR 
end  record; 


;  NET_AOOR; 

:  NET.AOOR; 

:  RECEIVE.CONTROL^PTR;  ••  Receive  Control  Field 
;  PRI0R1TY_TYPE; 

:  SEOUEMCE_TYPE;  ••  offset  to  sequence  counter 


type  REPLY_^N00E_TYPE  is  (NOJEPLY,  REPLY); 


type  RECElVE.CONTROL_TYPE<REPLY_MOOE 
COMMAND  :  WORD  range  0..8; 

PROC.IO  :  WORD; 

TASX.IO  :  WORD; 

ENTRY.ID  :  WORD; 

case  REPLY  is 
when  TRUE  ■> 


REPLY_M00EJYPE)  is  record 
*■  see  conmand  table  below 
■*  processor  10 


TX_CONTROL  :  TRANSMIT_CONTROL_TYPE; 
when  FALSE  ■> 
null; 
end  case; 


end  record; 


TX_elaborate_begin: 

DEF_brsvo_address  <> 

0EF_alpha_addres8  <> 

dw  OFFSET  RX.elaborate^begin  ;  RECEIVE  CONTROL 

At  0  ;  priority 

dw  OFFSET  BRAVO.SEQUENCER  ;  sequence  pointer 


RX_el aborste_beg i n: 
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dw 

DEF_elab_begin 

;  efaborate  begin  COMMAND 

du 

OEF_pid_bravo 

;  dest.  Proc  ID  (bravo) 

du 

offset  Main_TCB 

;  dest.  Task  ID  (Main) 

dw 

offset  Main_TCB.EMTRY1_Q 

;  entry  *  elaborate 

reply  Transmit  control  record 
OEF_a(pha_address  o 
OEF_bravo_address  <> 
dw  OFFSET  RX_elabor8te_end 

du  0 

dw  OFFSET  ALPHA  SEQUENCER 


;  RCP 

;  priority 
;  sequence  pointer 


8X_elabor8te_end: 

dw  DEF_elab_end 

dw  DEF_pid_alpba 

dw  offset  Main_TC8 

dw  offset  Main  TCB.ENTRY1  Q 


;  COMMAND  a  Elaborate  End 
;  dest.  Proc  ID  (alpha) 

;  dest.  Task  10  (MAIN) 


TX_report_begi n_ent ry : 

DEF_bravo_address  <> 

0EF_alpha_,addre8a  <> 

dw  OFFSET  RX_report_beflin_entry  ;  COMMAND  •  beflin  entry 

dw  0  ;  priority 

dw  OFFSET  SRAVO.SEQUENCER  ;  sequence  pointer 


RX_r  epo  r t_beg i n_en t  ry : 

dw  OEF_request_entry 

dw  OEF  _pid_bravo 

dw  offset  Reportbuf_TCB 

dw  offset  Reportbuf _TCB. ENTRY 1_Q 

;  reply 

DEF_alpha_address  <> 
DEF_br8vo_address  <> 
dw  OFFSET  RX_report_end_entry 

dw  0 

dw  OFFSET  BRAVO_SEQU£NCER 


;  COMMAND  *  begin  entry 
;  dest.  Proc  ID  (bravo) 

;  dest.  Task  ID  (Report_Buf) 
;  entry  »  GET_NEXT_REPORT 


;  COMMAND  ■  accept  complete 
;  priority 
;  sequence  pointer 


RX_report_end_entry; 

dw  OEF_accept_complete 

dw  DEF_pid_alpha 

dw  offset  Control  TCB 


COMMAND  s  accept  complete 
dest.  Proc  ID  (alpha) 
dest.  Task  ID  (Control) 
caller  entry  is  not  required 


TX_gu i de_beg i n^ent ry ; 

DEF_bravo_address  <> 

DEF_alpha_address  <> 

dw  OFFSET  RX_guide_begin_entry  ;  COMMAND  «  begin  entry 

dw  0  ;  priority 

dw  OFFSET  BRAVO.SEOUENCER  ;  sequence  pointer 
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[_gu i de.beg i n_en t ry : 

dM 

DEF_request_entry 

* 

CQMUNO  B  begin  entry 

dN 

DEF.pid.bravo 

• 

dest.  Proc  ID  (bravo) 

dw 

offset  Guidefauf.TCB 

« 

dest.  Task  ID  (Guide.Buf) 

du 

offset  Guidebuf_TCB.EHTRY2.Q 

9 

entry  b  Put.NEXT.CUIOE 

;  reply 

DEF.alpfta.address  o 

OEF.bravo.address  <> 

du 

OFFSET  RX.guide_end_entry 

RCP  COMMAND  ■  accept  coaplete 

dw 

0 

priority 

dw 

OFFSET  ALPHA.SEQUENCER 

sequence  pointer 

[_gui de_end_ent ry ; 

dw 

DEF.accept.cemplete 

;  COMMAND  *  accept  coaplete 

dw 

OEF  j>id_alpha 

;  dest.  Proc  10  (alpha) 

dw 

offset  Control.TCB 

;  dest.  Task  ID  (Control) 

4 

;  caller  entry  not  required 

TX_tracK^befli n_entry! 

0EF.br a va_addrMS  <> 
OEF.alpha.addraas  o 


dw 

OFFSET  RX.track.begin.entry 

;  COMMAND  b  begin  entry 

0 

;  priority 

dw 

OFFSET  BRAVO.SEQUENCER 

:  sequence  pointer 

RX_t  rack.beg  f  n.ent  ry ; 

dw  OEF_request_«ntry 

dw  OEF  jsid.bravo 

dw  offset  Targsup.TCB 

dw  offset  Targsup.TCB.ENTRYI.O 

.•reply 

DEF.a I pba.addr ess  <> 
DEF.bravo.address  <> 
dw  OFFSET  RX.track.end.entpy 

dw  0 

dw  OFFSET  ALPHA  SEQUENCER 


;  COMMAND  >  begin  entry 
;  dost.  Proc  10  (bravo> 

;  dost.  Teak  ID  (Targ.Sup) 
;  entry  ■  Set.Target.Msg 


;  COMMAND  a  accept  complete 
;  priority 
;  sequence  pointer 


RX_trock_end_entry; 

dw  DEF.accept.complete 

dw  DEF  _pid.alpha 

du  offset  Track  TCB 


;  COMMAM)  ■  teetpt  complete 
;  dest.  Proc  ID  (alpba> 

;  dost.  Task  ID  (Track) 

;  caller  entry  not  required 


ALPHA.SEQUENCER  dw  0 

BRAVO.SEQUENCER  dw  0 
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;  For  now,  all  tasks  have  at  n»st  two  entries,  therefore  this  is 
;  static. 

t 

;  The  TC8  contains  a  Synchronize  sesaphore  which  is  used  to 

;  suspend  itself  and  wait  for  a  signal  froai  another  task. 

;  This  is  followed  by  a  list  of  entry  records.  Each  entry  record 
;  contains: 

;  -  A  waiting  flag  used  by  the  accepting  task  to  indicate  that  it 

;  has  suspended  waiting  for  a  call  on  this  entry  (and  possibly 

;  others). 

;  -  A  buffer  List  Pointer,  This  points  to  the  buffer  descriptor 

;  for  the  first  caller  to  this  entry.  The  buffer  descriptor 

;  provides  the  actual  buffer  address  and  a  link  to  the  next 

;  descriptor.  This  provides  the  FIFO  queue  for  each  entry. 

t 

;  In  the  case  of  the  MAIM  program.  Entry!  is  used  for  elaboration 
;  control  of  library  units. 

i 

TCB  struc 

SYNC^SENAPHOEE 
EHTRY1_Q 
EMTRY2_Q 
KEPLY_PTH 
TCS  ends 

M8in_TC8  TCS  <> 

Targsup^TCB  TCB  <> 

Rocksup_TCB  TCB  <> 

Guidebuf.TCB  TCB  <> 

Reportbgf_TC8  TCB  <> 

Track_TCB  TCB  <> 

Control  TCB  TCB  <> 


0U‘  3  dup  (0)  ;  to  synchronize  rendezvous 

OU  2  dup  (0)  ;  waiting  flag,  next  ptr 

DW  2  dup  (0)  ;  waiting  flag,  next  ptr 

DW  0  ;  pointer  to  replies 


end 
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ptge  55,132 

TITLE  RTE  -  Distribted  Ada  RuntiM  Noduls' 


FILE:  DA.RTE.AStt 

RTE  -  DISTRIBUTED  Ada  RUNTIME  NODULE 

Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
Derivation  :  LabTek  Distributed  Ada  VI .0 

This  Distributed  Ada  Rwitime  Inherits  the  LabTek  copyright. 
The  following  copyright  nust  be  Included  in  all  software 
utilizing  this  Ada  Runtlnw. 

Copyright  1989  by  LabTek  Corporation,  Woodbridge,  CT,  USA 

Permission  to  use,  copy,  modify,  and  distribute  this 
software  and  Its  docunentatlon  for  any  purpose  and  without 
fee  Is  hereby  granted,  provided  that  tha  above  copyright 
notice  appear  In  all  copies  and  that  both  that  copyri^t 
notice  and  this  permission  notice  appear  in  supporting 
docunentatlon,  and  that  the  name  of  LabTek  not  be  used  In 
advertising  or  publicity  pertaining  to  distribution  of  the 
software  without  specific,  written  prior  permission. 

LabTek  makes  no  representations  about  the  suitability  of 
this  software  for  any  purpose.  It  Is  provided  "as  is" 
without  express  or  Implied  warranty. 

Disclaimer  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 

This  software  and  its  docunentatlon  are  provided  "AS  IS"  and 
without  any  expressed  or  implied  warranties  whatsoever. 

No  warranties  as  to  performance,  merchantability,  or  fitness 
for  a  particular  purpose  exist. 

In  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damages  or  lost  profits. 

: ; ; ; : ; ; ; ; ; ; ; ; ; ; ; ;  end  -prologue  ; ; ; ; ; ; ; ; ; ; ; ;;;;;;;; ; ; ; ; ; ; ; ; ; ; ; ; ; 


Runtime  Code  to  implement  prototype  Distributed  Ada  Services 

This  module  implements  the  remote  rendezvous  operations  to 
support  dlstributad  Ada. 

Currently  provided  are: 

Remete_Entry,  Ramote_Select,  Ramote_Accept,  Remote_End_Accept, 
Remote_Elab_$tart,  Remote_Elab_Uait,  Ramote_Elab_Continue. 
Local.End.Accapt 
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V*r  Date  Descriptfon 
0.1  Mov>88  :  Initial  prototype 


.model  large 


public  Initialize 

public  Reiiiote_Entry,  Local_Entry,  Any_Select 

public  fte(note_Accept,  Remte_End_Accept.  Local_EndJlccept 

public  Rcmote_Elab_Start,  Remote_Elab_Wait.  ReiMte_Elab_Continue  public  NET_Receive 


;  Vendor  Runtime  Services 


extm 

VRTIF_Wait:far 

extm 

VRTIF_Signal_l:far 

extrn 

'vRTIF_Signal:far 

Network  10  Services 

extm 

TX_REAOT;near 

extrn 

IO_XMlT:near 

extm 

lO_Network_lni t:neor 

extrn 

IO_ALLOCATe:near 

extm 

IO_OEALLOCATE:near 

;  Vendor  Supplied  P  Semaphore  operation 
;  Vendor  Supplied  V  operation/ interrupt 
;  Vendor  Supplied  V  operation 

;  Transmit  ready  semaphore 
;  Start  transmission  routine 

;  allocate  a  buffer 
;  deallocate  a  buffer 


include  OA  OEF.ASli 


;  system  definitions 


;  calle 


cseg  segment  conmon 

assume  cs : cseg, ds: cseg, es: cseg 
org  600H 


;  Initialize  --  no  parameters 
§ 

Initialize: 

call  IO_MetMork_Init 
retf 


ELABORATE.START: 

This  routine  is  called  by  MAIN  to  elaborate  library  packages  on 
remote  processors.  After  sending  the  start  message  to  the  designated 
processor,  this  routine  suspends  the  current  task  (main)  waiting  for 
the  CONTINUE  reply. 

Inputs:  TASK_1D  (of  main) 

Transmit  Control  pointer  (pointer  to  appropriate  start  msg) 
(Xitputs:  AX  contains  the  Result  code  of  the  elaboration  (Zero  if  OK). 
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l  ab.Star  t : 
push  bp 

■ov  bp,sp 

;  upon  ontry  to  elaborate  start,  the  paraaieters  on  the  stack 
;  provide  the  Transmit  Control  Ptr  necessary  to  generate  the  start  msg. 


call 

lO.Xmit 

push 

cs  ; 

vendor  Uait  needs  sepnent  *  too 

push 

Chp^EF_task_id]  ; 

first  item  in  TCB  is  semapi.ore 

call 

VRTIF_WAIT  ; 

wait  for  elaboration  to  complete 

Mow  elaboration  has  completed,  get  result  and  deallocate  receive 

buffer 

mov 

bx,  thp*OEF_task_id3  ; 

get  my  TCB 

add 

bx,0EF_TC8_EI0  ; 

point  to  entry  Q  1 

call 

REMGVE  ; 

pull  entry  of  queue  (BX  ptr) 

push 

•word  ptr  Cbx-»data_f  ield] ; 

fetch  completion  status 

call 

10_OEALLOCATE 

pointed  to  by  BX 

pop 

ax  ; 

get  completion  status  into  AX 

pop 

bp 

retf 

;  ELABOilATE_UAlT  :  Suspends  a  task  until  it  is  given  the  signal 
;  to  continue  from  the  elaborating  processor. 

;  Go  to  Sleep  on  the  Semaphore  of  the  calling  task. 

;  IliPUTS; 

;  TASK_I0 

;  EMTRYJO 

Remote_E I ab_Ua i t : 

push  bp 

mov  bp,sp 


First,  check  to  see  if  there  is  already  a  message  tMiting  on 
the  specified  entry... 

mov  si ,  tbp^EF_Entry]  ; 

pushf  ;  preserve  interrupt  status 

cli  ;  go  atomic 

test  word  ptr  [s{'K)EF_Next_Ptr]  ,0FFFFH  ;  see  if  anything  on  entry 

jnz  REU010  ;  go  on  if  no  wait  necessary 

mov  word  ptr  tsi},1  ;  set  UAITIHG  Flag 

push  cs  ;  vendor  P  routine  needs  segment 

push  word  ptr  Cbp*OEF_task_id] 

call  VRTIF_UAIT  ;  this  also  reenables  Interrupts 
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REWOtO: 

;  After  resunption,  the  wekeup  messege  is  on  the  mein  tesk's  entryl, 

;  it  ui I I  be  processed  later  during  the  elaborate  continue  procedure. 

popf  ;  restore  interrupt  status 

pop  bp 

retf 


;  ELABORATE_CONTtNUE  :  Motifies  the  elaborating  processor  that 
;  the  specified  elaboration  in  complete  and 

;  that  it  can  continue  elaboration  of  other 

;  tftits. 

*  / 

;  Send  "End_Elaborate«  message  to  the  processor  that  allowed 
;  the  elaboration  to  continue,  as  determined  by  the  start  msg 

;  still  queued  to  Mains  entryl 

;  inputs:  Task^IO 

;  EMTRY_I0  on  entry,  changed  to  transmit  control  pointer 

;  number  of  parameters  :  always  ZERO 

Rcrotjte  ';lab_Continue; 


push 

bp 

mov 

bp.sp 

mov 

bx,  tbp^EF_Entry] 

;  fetch  entry  id 

call 

REMOVE 

pull  buffer  descriptor  off  entry  queue 

fflOV 

si, Cbx] 

fetch  actual  buffer  address  into  SI 

mov 

si, tsi*RCP] 

get  receive  control  pointer  from  rev  buffer 

Now  we  are  done  with  the  received  buffer,  release  it 

call  IO_Deal locate  ;  release  buffer,  descriptor  in  BX 

lea  ax,  Csi*OEF_ref>ly_offset]  ;  fetch  reply  message  pointer 

iMv  tbpH)EF^TCP],ax  ;  put  on  stack  for  XMIT_IO  in  Transaiit  control 

call  lO_Xfflit  ;  transmit  messege  pointed  to  by  BX 

pop  bp 

retf 


Remote_Entry 

Send  ''Request_Entry"  message  with  IN  parameters 
Wait  on  Entry_Uait_Semaphore 
Copy  OUT  parameters 
Release  Buffer 
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;  PAIUMETERS:  TASK.IO 

;  TRANSMIT  COHTROL_PTR 

NUM  IN  PARAMS 

;  IN_PARANI  (Offset, segment, length) 

;  IN_PARAMn  (off set, sevnent, length) 

;  NOTE:  Stock  Perimeters  ere  removed  by  celler 
Remote_Entry: 


push 

bp 

mov 

bp.sp 

call 

I0_Xmit 

wait 

for  Accept  Complete  to 

wake  up 

push 

cs 

mov 

'ax,  tbpH)£F_task_idl 

;  point  to  parameters 

push 

ax 

;  offset  of  seawphore  (TCB) 

call 

VRTIF^Wait 

;  go  to  sleep 

pop 

retf 

bp 

Locsl_Entry  :  This  routine  is  celled  for  en  entry  of  e  task 

which  is  local  (same  processor)  as  the  caller 
Inputs:  SRC*TASK_I0 
OST-TASKJO 
DST-EMTRY_I0 

PARAMTER  ADDRESS  (OFFSET, SEGMENT) 

Although  the  task  is  local  to  the  caller,  en  10  buffer  is  allocated 
to  store  the  necessary  pointers  required  by  accepting  tasks.  This 
is  later  deallocated  as  part  of  the  local_cnd_accept  routine.  The 
calling  task  is  always  suspended,  and  if  the  accepting  task  is  "waiting" 
it  is  signaled  to  wake  up. 


src_task_id 

dst_task_id 

dst_entry_id 

entry_peram 

Locol_Entry: 

push 

mov 

call 

mov 


equ  6 

equ  8 

equ  10 

equ  12 


bp 

bp.sp 

I0_Al locate 
si,(BX] 


;  get  a  buffer  descriptor  ptr  in  BX 
;  fetch  buffer  address 


;  currently  only  one  parameter  is  used  (either  in  or  out).  Take  advantage 
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of  this  to  sinpUfy  interface  to  accepting  task.'  The  address  of  the 
data  area  is  provided  in  the  first  part  of  the  buffer.  MOTE:  this  address 
is  backwards  (segnient>lOH  address,  offset>high  address). 


nov 

ax,  Cbp»entry_paraiti]  ; 

get  offset  of  param 

nov 

[si-»2],ax 

mov 

ax, [bp»entry_paramf2)  ; 

and  segment 

nov 

tsi),ax 

nov 

[si'*'4],bx  ; 

stuff  buffer  descriptor  in  buffer  too 

mov 

ax, [bp+src_task_id]  ; 

fetch  our  task  id 

mov 

[si+OEF_local_task_id)  ,ax 

;  ano  put  in  calling  task  id  there 

mov 

si ,  Ibp*dst_entry_id]  ; 

fetch  entry  queue  head 

ATOMIC  acti■'Jl^  follows...  Queue  entry, 

if  waiting  signal  acceptor 

pushf 

cli 

call 

INSERT  ; 

place  buffer  descriptor  on  entry  Q 

mov 

si, fbp*dst_entry_id]  ; 

fetch  entry  address  again 

test 

word  ptr  (sil.OFFFFH  ; 

see  if  WAITING 

j* 

le010 

go  on  if  not 

server  is 

waiting  on  accept,  signal  it 

mov 

si ,  tbp4dst_task_id]  ; 

get  task  id 

mov 

word  ptr  Ui-K)EF_TCB.E101 

,0  ;  clear  (all)  waiting  flacs 

mov 

word  ptr  Csi-K)EF_TCB_EIO*OEF_TCB_ENTRY_SUE]  ,0  ;  get  other  entry 

push 

cs 

;  segment  of  semaphore 

mov 

ax,  CbpKlst^taak^fd] 

push 

ax 

call 

VRTIF^Signal  ; 

wake  up  server  (may  preempt  ourselves) 

NOTE:  This  is  the  end  of  the  atomic  region  (above  Vendor  runtime  call 
reenables  interrupts! 


Ie010: 


(.'•pf 

;  restore  interrupt  level 

push 

cs 

;  now  try  to  suspend  ourselves 

mov 

ax,  [bp«'src_task_id] 

push 

ax 

cal  1 

VRTIf_Wait 

;  may  not  suspend  if  server  is  higher 
;  priority  and  has  already  signaled  usi 

pop 

retf 

bp 

;  Any_Select 
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;  Check  to  tee  ff  any  of  the  entries  have  callers.'  If  not, 

;  set  the  ’Malting''  Flag  in  each  of  then,  and  go  to  sleep. 

;  If  one  entry  has  a  queued  request,  accept  it  and  return 
;  offset  for  "Case"  table  in  DI  and  Entry  pointer  in  C$:BX. 

;  Note  that  this  routine  provides  the  synchronization  and  buffer 
;  nanagenent  ftawtions  only.  Separate  code  in  the  "LINK" 

;  andule  is  necessary  to  facilitate  parameter  transfer. 

;  Parameter  Sequence: 

;  BPt6  s>  Task_I0  (Always  Current  Teak) 

;  Ncinber  of  open  select  alternatives 

;  Entry_ID  #1 

;  Entry_lD  #n 

;  PARAMETERS  ARE  REMOVED  FROM  STACK  BY  CALLER 

¥ 

;  Output  Paraawters:  SI  -  selection  entry  id 

;  ES  •  data  segment 

;  BX  •  data  offset 

entry_couit  equ  8  ;  offset  from  BP  for  entry  count 

entry_llst  equ  10  ;  offset  from  BP  for  entry  list  start 

Any^Select: 

push  bp 

a»v  bp,sp 


;  ENTER  CRITICAL  REGION  (cannot  allow  task  to  go  on  an  entry  queue 

;  after  we  have  checked  it,  but  before  setting  waiting  flag. 

/ 

pushf 

cli 

t 

;  First  check  each  entry  to  see  if  any  has  a  caller... 

t 

Rem_Sel00:  ;  will  come  back  here  after  resiaae 

laov  cx,entry_count(bp]  ;  nurtwr  of  entries 

;  normaly  night  want  to  put  OR  CX,CX  ;  JZ  raise  progran^error  XX 
;  since  all  entries  are  closedi  XX 

nov  si,0  ;  entry  index 

Rcm_Sel10: 

nov  di,entry_listtbp''Si]  ;  get  next  entry  ID 

test  word  ptr  (di'»DEF_Next_Ptr] ,0FFFFH  ;  see  if  an  caller  is  queued 

jnz  Ram_SelS0  ;  if  caller  is  present,  go  select 

add  si, 2  ;  go  to  next  entry  in  list 

loop  Rem.SellO 


•222. 


Demonstration  Project  Final  Report 


all  of  the  Entry  Queues  are  Empty,  mark  each  Waiting  flag 
and  go  to  sleep. 


nov 

si,0 

;  reset  pointer 

oov 

cx,entry_count [bp] 

;  fetch  nMber  of  entries  again 

Rem_Sel30: 

nov 

di ,entry_l ist  tbp»si] 

;  fetch  entry  id 

mov 

word  ptr  [di],1 

;  set  WAITING  flag 

add 

si,2 

;  goto  next  entry 

loop 

Rem_Sel30 

« 

;  The  following  runtime  call  will  suspend  this  task,  when  it 

;  resumes. 

the  interrupt  flag  will 

be  set  again,  and  presuaably. 

;  one  of  the  entries  will  have  a  caller  queued. 

i 

push 

cs 

;  push  segment  of  wait_sefflaphore 

push 

thpH)EF_ta8k_id] 

;  push  offset  of  wait_semsphore  task id 

call 

VRTlF_Uait 

;  do  wait  on  semaphore 

,*  Now  clear 

all  the  waiting  flags 

cli 

inov 

si,0 

;  reset  pointer 

mov 

cx,  tbprentry_co«it] 

;  fetch  number  of  entries  again 

Rem  SeUO: 

mov 

di , entry_l i st Cbp*s i  ] 

;  entry  list  on  stack 

mov 

word  ptr  Cdi] ,0 

;  clear  waiting  flag 

loop 

Rem_SeU0 

imp 

Rem_Sel00 

;  go  back  and  find  caller 

« 

a 

;  There  i s 

a  caller  on  this  entry  queue,  do  start  accept 

:  Fetch  the  Caller's  buffer,  which 

has  a  (backward)  pointer  to 

;  the  parameter  data 

• 

Rem^SelSQ: 

mov 

di,Cdi+OEF_Mext_Ptr] 

;  get  buffer  descriptor 

mov 

bx,[di] 

;  fetch  buffer  address 

mov 

ax, si 

;  get  selector  into  AX 

thr 

ax,1 

;  get  cowit 

Inc 

ax 

;  to  be  coagMtible  with  VRTIF 

popf 

;  restore  interrupt  status 

pop 

bp 

retf 

;  parameters  are  rcmovad  by  caller 

Remote  Accept  (TASIC_I0,  ENTRT_I0)  return  ES:BX_Raraia_Pointer 
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Simple  Accept,  see  if  soswone  on  entry  queue,  if  so 
return  with  pointer  to  buffer  in  ES:BX,  otherwise  set 
"Waiting*  Flag  and  go  to  sleep  on  semaphore. 

Inputs;  TASKJD,  ENTRY JD 

Outputs:  Returns  ES:BX  pointing  to  Parameter  Oats  List 


Remote_Accept: 

push  bp 

mov  bp,sp 

mov  si , CbpH>EF_Entryl  ;  fetch  address  of  entry  Q 
pushf  ;  save  interrupt  status 

cli  ;  go  atomic 

test  word  ptr  tsi'K)EF_IIEXT_PTR]  ,0FFFFH  ;  if  Zero,  then  list  is  empty 
jnz  RA010  ;  if  caller  is  there,  take  itl 


Ho  caller 


on  entry  queue. 


Set  waiting  flag  and  go  to  sleep 


mov 

push 

mov 

push 

call 

NOTE  after 


word  ptr  Csi],1  ;  set  flag 

es  ;  push  segment  of  my  task  semaphore 

as, (bprOEF^task_id]  ;  get  address  of  TCB 

ax 

VRT1F_UAIT  ;  go  to  sleep  waiting  for  caller 
vendor  runtime  call  *  interrupts  are  cnabledi 


;  Now  Something  is  on  the  queue,  provide  address  of  data  area  in 
;  ES:BX  and  return  to  caller. 

RADIO: 

popf  ;  restore  interrupt  status 

mov  si, [bp«OEF_Entry];  get  entry  address  again 

mov  si,  Csi'H)EF_NEXT_PTR]  ;  get  address  of  buffer  descriptor 

mov  bx, tsil  ;  fetch  actual  buffer  address 

mov  sx,cs  ;  provide  caller  with  segment  of  data 

mov  es,ax 

mov  Cbx],ax  ;  put  data  address  as  first  words  in  buffer 

lea  ax, {bx'»data_field]  ;  but  written  backwards 

mov  [bx«2],ax 

pop  bp 

retf 


:  Remote_End_Accept 

;  Send  output  parameters  to  caller. 

;  Release  buffer  used  to  hold  input  (and  output  for  now)  parameters. 
Remote_End_Accept : 
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bp 

bp.sp 


push 

WJV 

■ov  bx, tbp+OEF_Entryl 
call  REMOVE 

push  bx 

MOV  s<,Cbx] 

mov  s{,Csf>RCP1 

Isa  BX,  tsi'K)EF_reply_offsetl 

mov  tbp*OEF_Ti:P]  ,ax 

call  lO.Xmit 

Mow  we  are  done  with  the  received 


fetch  entry  queue  pointer 
pull  it  off  queue,  leaving  BX  «  BUFPTR 
save  buffer  descriptor  pointer 
fetch  actual  buffer  address  into  SI 
get  RCP  from  rev  buffer 
fetch  reply  message  pointer 
replace  ENTRY  on  stack  with  TCP 
transmit  reply 


buffer,  release  it 


pop  bx  ;  get  descriptor  ptr  back 

call  IO_Oeal locate  ;  release  buffer,  descriptor  in  BX 

pop  bp 

retf  / 


;  Local_End_Aceept 

;  Allow  caller  to  continue  (Note:  this  is  for  entry  cal  la  with  parameters 

;  that  are  all  passed  by  reference.  No  oopyback  is  required). 

;  All  entries  whether  remote  or  local  use  a  buffer,  therefore  deallocate 
;  it  when  complete. 

Loca l_EndJlccept : 

push  bp 

mov  bp,sp 

mov  bx,  tbpH)EF_local_entry_id]  ;  fetch  entry  ID 

call  REMOVE  ;  pull  entry  off  queue  BX  now  a  buffer 

mov  si,(bx]  ;  get  buffer  address 

push  cs  ;  push  segment  of  semaphore 

push  word  ptr  [si>OEF_local_task_id]  ;  push  calling  Task's  ID 

call  IO_Deal locate  ;  deallocate  buffer  a  BX 

call  VRTIF_Signal  ;  signal  task  to  continue 

pop  bp 

retf 


Net_Rcceivc  -  processes  an  incoming  message 

This  routine  is  called  by  the  interrupt  handler  (in 
the  10  Nodule)  to  initiate  action  based  on  tha 
receipt  of  a  packet.  When  the  service  handler  is 
called,  BX  contains  the  address  of  tha  buffer 
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;  dMcrfptor,  SI  contains  the  RECEIVE  CONTROL  POINTER.  ; 


Net^Rectlvc: 

■ov 

si.Cbxl 

;  get  address  of  actual  buffer 

■ov 

si,Isi+RCP] 

;  Receive  control  pointer 

MOV 

di ,  tsi'H)EF_c»d_of  f  set] 

;  fetch  coimnd 

and 

di ,vector_mask 

;  mask  for  valid  vector  values 

j*np 

vector [di] 

The  following  vector  table  inpleawnts  the  'case'  statanent 
on  the  message  ACTION  field 


vectorjnask 
vector  label 
dw 
dw 
dw 
dw 


equ  000001 108  ;  valid  range  0*6 

word 

offset  Begin_Elaborate 
offset  End_Elaborate 
offset  Request_Entry 
offset  Accept_Coflf>lete 


Future  versions  of  the  vector  table  will  include 
Beg i n_Remo ve_Ent  ry 
End_R«iiove_Entry 
Begin_Abort 
End.Abort 
Begin^Terminate 
End_Teniiinate 
Shared_Vari able^Request 
etc. 


This  code  section  is  executed  upon  receipt  of  a  message  initiating 
a  Begin_Elaborate  request.  BX  points  to  buffer  descriptor. 


Begin^Elaborate 

mov 

di,[bx] 

get  data  buffer 

mov 

di , tdi«RCP] 

fetch  receive  control  pointer 

mov 

si ,  tdi'»0EF_eid_offset] 

get  entry  10 

call 

INSERT 

put  buffer  on  entry  queue 

push 

cs 

semaphore  segment 

push 

tdi+OEF_tid_offset] 

push  task  id  of  destination 

call 

VRTIF_Signal_I 

signal  task  to  continua 

ret 

This  cede  section  is  executsd  upon  receipt  of  a  massage  initiating 
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;  an  End_Elaborate.  This  Message  implies  that  the  specified  elaboration  has 
;  been  completed  on  the  remote  processor  stid  elaboration  can  continue 
;  on  the  primary  processor. 

;  INPUTS:  BX  points  to  buffer  descriptor. 

End_Elaborate: 


nov 

si , [bx] 

get  buffer  address 

mov 

si ,  [si-^RCP] 

fetch  receive  control  pi 

push 

cs 

semaphore  Segment 

mov 

ax,  [si'H)EF_tid_offset] 

semaphore  Offset 

push 

ax 

mov 

si,  tsi'H)EF_eid_offsetl 

get  entry  id  offset 

mov 

word  ptr  (si],0 

clear  WAITING  FUG 

call 

Insert 

put  on  caller's  queue 

call 

VRTlF_Signal_I 

signal  task  to  continue 

ret 

;  This  code  section  is  executed  upon  receipt  of  a  message  initiating 
;  an  entry  call 

;  Place  buffer  on  Entry  queue,  If  •Maiting"  for  that  entry  is  fPUE, 

;  clear  all  Waiting  Flags  and  signal  Wait  Semaphore. 

;  INPUTS: 

;  BX  s  Buffer  descriptor  pointer 
;  SI  >  Receive  control  pointer  (RCP) 

Request^Entry: 

mov  dx,  [si-H)EF_tid_offset]  ;  save  task  id  for  later 

mov  si, Csi'»OEF_eid_offset]  ;  fetch  entry  id  for  later 

mov  di,(BX]  ;  fetch  buffer  address  (again) 

$ 

;  currently  only  one  parameter  is  used  (either  in  or  out).  Take  advantage 
;  of  this  to  simplify  interface  to  accepting  task.  The  address  of  the 

;  data  area  is  provided  in  the  first  part  of  the  buffer.  NOTE:  this  address 

;  is  backwards  (segment^low  address,  offset>high  address). 


lea 

ax,  tdi-Kiata.field) 

;  get  offset  of  parameter 

mov 

(di-^Zj.ax 

mov 

ax,cs 

;  and  segmant 

mov 

Cdi]  ,ax 

mov 

Cdi«4] ,bx 

;  stuff  buffer  descriptor  in  buffer  too 

ATOMIC  action  follows...  Queue  entry,  if  waiting  signal  acceptor 

pushf 

eli 

mov  cx,(si]  ;  get  WAITING  flag  for  this  entry 
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call  INSERT  ;  place  buffer  daeeriptor  on  entry  0 

or  cx,cx  ;  teat  tiaitlng  flap 

Jz  reOlO  ;  go  on  if  not 


server  is  waiting  on  accept,  signal  it 


« 

MOV 

si.dx 

;  get  task  id 

MOV 

word  ptr 

Csi^EF_TCB_EID]  ,0  ;  clear  (all)  waiting  flags 

MOV 

word  ptr 

Csi'H)EF_TCB_EID+OEF_Tl»_ENTRY_SI2EJ,0  ;  get  other  entry 

push 

cs 

;  segment  of  semaphore 

push 

si 

;  offset  of  semaphore  (first  in  TCB) 

esU 

VRTIF_Signal_I  ;  wake  up  server 

r 

reOlO: 

popf 

;  restore  interrupt  level 

ret 

:  return  to  interrupt  handler 

ACCEPT_COMPLEIE  - 

This  code  section  is  executed  upon  receipt  of  a  message  coapleting 
an  accept  body  (end  rendezvous) 

Post  buffer  containing  Out  Parameters  and  signal  task  to  wake  up 
INPUTS: 

BX  «  Buffer  descriptor  pointer 
SI  «  Receive  control  pointer  (RCP) 


Accept.Complete: 


aiov 

si ,  tsi-H)EF_tid_off set) 

;  fetch  task  id  of  caller 

mov 

l8i+0EF_TCB_REPLT),bX 

;  provide  caller  with  reply  buffer 

push 

cs 

;  push  segment  of  caller  semaphore 

push 

si 

;  push  offset  of  same  (TCB) 

call 

VRTIF_SignalJ 

;  wake  up  caller 

ret 

;  to  finish  interrupt 

REMOVE  •  Remove  Entry  that  is  on  entry  queue 
Inputs:  BX  points  to  entry  Q 

Output:  BX  points  to  buffer  descriptor  that  was  dequeued 
All  other  registers  are  preserved 


REMOVE: 

push  ax 
push  si 
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;  do  list  operation  as  atomic  action 


pushf 

cU 

mov 

si , tBX*OEF_NEXT_PTR] 

t 

fetch  buffer  descriptor 

MOV 

ax,  tsi'K)EF_NEXT_PTR] 

s 

get  next  buffer 

MOV 

tBX*OEF_NEXT_PTR]  ,ax 

t 

update  queue  head 

popf 

mov 

bx.si 

0 

return  pointer  in  BX 

pop 

si 

pop 

ax 

ret 

INSERT  -  INSERT  Entry  onto  the  end  of  an  entry  queue 

Inputs:  SI  ppints  to  entry  0 

BX  points  to  buffer  descriptor 

Outputs:  SI  points  to  last  entry  on  Q 

All  other  registers  are  preserved 


INSERT: 

ax 

I 

;  do  list  operation  as  atomic  action 
» 

pushf 

cli 

INSERT10: 


mov 

ax,  Csi-»OEF_next_ptr] 

;  get  next  buffer  on  entry  ( 

or 

ax, ax 

;  see  if  end  of  list 

jz 

INSERT20 

;  end  of  list,  go  insert  it 

this  is  not 

end  of  list,  Xeep  searching 

mov 

si, ax 

jmp 

INSERT10 

found  spot 

on  list,  insert  it 

INSERT20: 

mov 

tsi*OEF_next_ptr] ,bx 

;  put  on  end  of  list 

popf 

;  restore  interrupt  flag 

mov 

bx,si 

;  return  pointer  in  BX 

pop 

ax 

ret 
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p«9«  55,132 

TITLE  Setup  •  Distributed  Ada  Network  Initialization 


;  FILE:  DA.SETUP.ASM 
;  Distributed  Ada  -  Setup 

;  This  module  initilizes  the  network  to  prepere  for  distributed 
;  processing. 

Distribution  end  copyright  ;;;;;;;;;;;;;;;;;;; 
;  Derivation  :  LabTek  Distributed  Ada  VI .0 


;  This  Distributed  Ada  Runtiiw  inherits  the  i.abTek  copyright. 
;  The  following  copyright  must  be  included  in  all  software 
;  utilizing  this  Ada  Runtim. 

;  Copyright  1989  by  LabTek  Corporation,  Uoodbridge,  CT,  USA 

;  Permission  to  use,  copy,  modify,  and  distribute  this 
;  software  and  its  docunentation  for  any  purpose  and  without 
;  fee  is  hereby  granted,  provided  that  the  above  copyright 

;  notice  appear  in  all  copies  and  that  both  that  copyright 

;  notice  and  this  permission  notice  appear  in  supporting 
;  docurrontation,  arxi  that  the  name  of  LabTek  not  be  used  in 

;  advertising  or  pi.^licity  pertainirtg  to  distribution  of  the 

;  software  without  specific,  writteti  prior  permission. 

;  LabTek  makes  no  representations  about  the  suit^ility  of 
;  this  software  for  any  purpose.  It  is  provided  "as  is" 

;  without  express  or  inplied  warranty. 


oisciaiirer  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 


;  This  software  and  its  docunentation  arc  provided  "AS  IS"  and 
;  without  any  expressed  or  implied  warranties  whatsoever. 

;  No  warranties  as  to  performance,  merchantability,  or  fitness 
;  for  a  particular  purpose  exist. 

In  r>o  event  shall  any  person  or  organization  of  people  be 
;  held  responsible  for  any  direct.  Indirect,  consequential 
;  or  inconsequential  damages  or  lost  profits. 


;;;;;;;;;;;;;;;;;;;  eno-prolocue  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 


.model  large 
public  Setup 


include  OA.HW.ASN 
cseg  segment  coemon 

assuee  cs : cseg, ds: cseg, as: cseg 
erg  OAOOH 

Setup: 
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■ov 
■ov 
out 
■ov 
out 
■ov 
out 
■ov 
■ov 
■ov 
■ov 
■ov 

GET.AODRESS: 

in  a(,dx 
stotb 
ine  dx 

loop  GET.AOORESS 


MOV 

dx.cntrl 

t 

select  no-sharing  adapter. 

mov 

a 1 , at h_rec v_se 1 ec  t 

a 

# 

and  external  transceiver 

out 

dx.al 

mov 

dx.gaefr 

i 

SIC  of  MMory  napped  space. 

mov 

al,ath.lan_conf ig 

i 

with  interrupts  enabled 

out 

dx.al 

■ov 

dx.dqtr 

a 

$ 

i  of  bytes  to  transfer  on 

■ov 

al ,  ath_ra«_OHA__burst 

$ 

a  remote  DMA  burst  (n/a) 

out 

dx.al 

■ov 

dx.idcfr 

0 

interrupt  IRQ  and  DMA 

■ov 

al.ath_irq_lina 

» 

channel  selection  (DHA  n/a) 

out 

dx.al 

■ov 

dx.damb 

f 

Sk  configurat{o.n  for  remote 

■ov 

a 1 , ath_ram_DHA_conf i g 

$ 

DMA.  Hot  used,  but  nininus 

out 

dx.al 

$ 

value  needed 

■ov 

dx.pstr 

9 

start  of  receive  buffer. 

mov 

al .ath_recv_buf_start 

9 

Value  MUST  natch  that  in 

out 

dx.al 

9 

MIC _patart 

mov 

dx.pspr 

9 

end  of  receive  buffer. 

■ov 

al .ath_racv_buf_and 

9 

Value  MUST  natch  that  in 

out 

dx.al 

9 

MIC JMtop 

mov 

dx.mc.er 

9 

stop  NIC  activity 

■ov 

■l.ath_n<e_stop 

out 

dx.al 

■ov 

dx.NIC_dcr 

9 

local  DMA  tranafera  aa 

dx.cntrl  ;  Goto  array  control  tar 

al , ath_enabl a_reset 

cte.al 

al ,ath_disable_rasat 
db(,al 

al , ath_accaas_pram 

dx.al 

ex, 6 

ax.ea 

aa,ax  ;  aat  aa:di  to  racaiva  board 

di, offset  BOARD_ADORESS  ;  address  fro«  pros 
dx,pran_address  0 
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SIVE  ADDRESS: 


MOV 

a 1 , at h_n i c_DMA_eonf 1 g 

out 

dx,al 

MV 

dx,NIC_rbcrO 

MV 

al ,eth_remote_DNA_lo 

out 

dx,al 

MV 

dx,NIC_rbcr1 

MV 

al , eth_refl»te_OMA_h i 

out 

dx,al 

MV 

dx,MIC_rcr 

MV 

a 1 , eth_packet_types 

out 

dx,al 

MV 

dx,N!C_tcr 

mov 

al,eth^nic_mobe 

out 

dx,al 

MV 

dx,NIC_bndy 

aiov 

e 1 , eth_bndy_s  tart 

out 

dx,al 

MV 

dx,NICjxtart 

MV 

al , eth_reev_buf_start 

out 

di(,al 

MV 

dx,NIC_pstop 

MV 

al , eth_reev_buf_end 

out 

dx,al 

MV 

d*,NICJsr 

MV 

a(,eth_int_status 

out 

dx,al 

fflOV 

ib(,NlC_isr 

MV 

al ,eth_i nts_ensbled 

out 

dx,al 

MV 

d*,NIC_cr 

MV 

al , eth_aecessj3ege_1 

out 

dx,al 

MV 

dx , phys_address_0 

MV 

ax,cs 

MV 

ds,ax 

MV 

si, off set  BOARO_ADDRESS 

MV 

cx,6 

;  8  fayt*  bursts 


;  rsMots  DMA  sstup  (rsmots 
;  OHA  not  used,  only  local 
;  used) 

;  hi  byte  of  f  of  bytes  to 
;  transfer  during  a  remote 
;  DMA  operation 

;  accept  runt,  errored,  broad 
;  cast  and  multicast  packets 

;  go  into  internal  loopback 
;  mode  to  fini  .h  prograsming 
;  (see  anomalies  *  p.  52) 

;  overwrite  protection  rgtr. 

;  (protects  unread  packets) 


;  start  of  receive  qimie 


;  end  of  receive  queue 


;  clear  interrupt  status 


;  enable  interrupts 
;  transmit  interrupts  are 
;  at  bit  02h 

;  access  page  1  registers 


;  let  NIC  know  its  address 


;  from  the  prom 
;  ncmber  of  addresses  to  give 


lodsb 

out  dx,al 
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FILL: 

BOARD. 

cseg 


Inc 

dx 

loop 

GtVE.ADDRESS 

;  load  all  addresses 

■ov 

d*,IIIC_curr 

;  load  currant  receive  pointer 

anv 

al ,eth_recv_buf_start 

;  with  patart 

out 

dx.al 

nov 

dx,MlC_cr 

;  access  page  0  registers 

■nv 

al  ,eth_acee88j>age_0 

out 

dx.al 

mov 

dx,MlC_cr 

;  start  HlC  chip 

nov 

al,eth_start_nic 

out 

dx.al 

nov 

dx,MIC_tcr 

;  exit  internal  loopback  node 

nov 

al,eth_exit_BBde 

out 

dx.al 

nov 

ax ,  net_ii«(nory_8eg 

:  initialize  LAN  nemory  to 

nov 

as. ax 

;  zeroes 

nov 

cx .  net_nw«ory_8  i  ie/2 

;  in  words 

xor 

di.dl 

;  start  at  begin  of  segaient 

cid 

nov 

ax. 0000 

;  initialization  value 

stosw 
loop  FILL 
ret 

.ADDRESS  db  6  <*4)  (7)  ,*  holds  board  address 

ends 
END 
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FILE:  0A_V*TIF 

Olstributad  Ada  *  Vendor  Runtime  Interface 

This  module  provides  the  addresses  within  the 

Vendor  supplied  runtime  for  required  tasking  primatives. 

Distribution  and  copyright  ;;;;;;;;;;;;;;;; 
Derivation  :  LabTek  Distributed  Ada  VI. 0 

This  Distributed  Ada  Rmtime  inherits  the  LabTek  copyright. 
The  following  copyright  must  be  included  in  all  software 
utilizing  this  Ada  Runtime. 

Copyright  1989  by  LabTek  Corporation,  Uoodbridge,  CT,  USA 

Permission  to  use,  copy,  modify,  and  distribute  this 
software  and  -its  docunentation  for  any  purpose  and  without 
fee  is  hereby  granted,  provided  that  the  above  copyright 
notice  appear  in  all  copies  and  that  both  that  copyright 
notice  and  this  permission  notice  appear  in  supporting 
docunentation,  and  that  the  name  of  LabTek  not  be  used  in 
advertising  or  publicity  pertaining  to  distribution  of  the 
software  without  specific,  written  prior  permission. 

LabTek  makes  i>i  representations  about  the  suitability  of 
this  so?t^<are  for  any  purpose.  It  is  provided  "as  is" 
without  express  or  implied  warranty. 

* / / i t t f f f t r t i t } i 7 t  Disclaimer  il i«<f #«««#? ?«###«# I#? i 

This  software  and  its  docunentation  are  provided  "AS  IS"  and 
without  any  expressed  or  implied  warranties  whatsoever. 

No  warranties  as  to  performance,  mrchantabi  I  i ty,  or  fitness 
for  a  particular  purpose  exist. 

In  no  event  shall  any  person  or  organization  of  people  be 
held  responsible  for  any  direct,  indirect,  consequential 
or  inconsequential  damn<]«s  or  lost  profits. 

;;#';#*;;#'#*;#*#'#*#'#'#'#’#*  end-prologue 


public  VRTIF_18259,  VRTIF_vector_base 
public  VRTIF_Uait,  VRTIF.Signal,  VRTIF.SignalJ 

VRTIF_I8259  equ  20H  ;  address  of  interrupt  controller  chip 

VRTIF_vector_base  equ  200H  ;  base  of  vector  table 

vrtif  segment  at  4000h 

org  3F56H 

VRTIF_^Uait  label  far  ;  R1TESS7P  P  semaphore  operation  (non-interrtjpt) 
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org  3F6CH 

VRTIF_S<gn»l  label  far  ;  R1TESS7V  V  semaphore  operation  (non- Interrupt) 

org  3F21H 

VRTIF_Signal_I  label  far  ;  R1TES17V1  V  semaphore  operation  (lnterri4#t) 

vrtif  ends 

end 
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21  Appendix  J  •  Key  Control  for  the  Border  Defense  System 

Version  1.0 


21.1  Purpose 

This  document  describes  the  technique  and  procedures  for  loading  and  verifying  encryption 
keys  used  by  the  Border  Defense  System  (BDS). 

21.2  References 

Data  Encryption  Standard,  U.S.  Department  of  Commerce,  National  Bureau  of  Standards, 
FIPS  publication  46, 1977  January  15. 

21.3  Key  Management 

Encryption  keys  used  with  the  BDS  shall  conform  to  the  Data  Encryption  Standard  (DES) 
format.  These  keys  consist  of  a  bit  string  of  56  binary  digits.  Keys  shaU  be  entered  as  7  pairs 
of  hexadecimal  digits,  each  pair  representing  8  bits  of  the  string.  A  minimum  of  1  space 
shall  be  entered  between  each  pair.  The  pairs  of  digits  shall  be  terminated  by  an  ASCII 
carriage  return.  No  other  characters  other  than  space,  carriage  return,  di^ts  0  through  9 
and  letters  A  through  Z  (case  insensitive)  are  permitted.  Note  that  parity  bits  are  not 
entered  into  the  BDS  (or  related  hardware)  by  users,  but  may  be  computed  internally  within 
the  system  to  augment  the  56  bit  string.  Keys  shall  be  provided  by  the  security  officer  prior 
to  system  initialization. 

Key  entry  shall  be  via  an  ASCII  keyboard  interface  in  either  upper  or  lower  case  characters. 
Keys  shall  be  entered  twice  to  verify  that  there  are  no  errors  cfuring  entry.  Keyboard  echo 
shsdl  be  disabled  during  key  entry.  BDS  equipment  shall  verify  keys  are  in  the  correct 
format  and  ensure  that  both  key  entries  are  identical. 

Each  BDS  system  component  requiring  a  key,  shall  not  become  fully  operational  until  after 
a  conforming  key  has  been  entered.  Key  entry  shall  be  accompanied  by  the  following 
messages,  as  appropriate: 


Prompt  1: 

ENTER  ENCRYPTION  KEY  ; 


Prompt  2:  (only  if  Key  entry  1  is  valid) 


REENTER  ENCRYPTION  KEY: 


Response  to  valid  entries: 
KEY  ACCEPTED 


Response  to  invalid  entries: 

KEY  REJECTED,  INVALID  FORMAT 
or 

KEY  REJECTED.  VERIFICATION  ERROR 


-237- 


